In light of the articles that I referenced, I'm leaning toward using coexpressions to implement aspects, e.g., for a class, the "initially" clause creates and activates an aspect-handling coexpression and then, to implement join points, transmit some helpful info to the coexpression, e.g.:
[self,"joinpointlabel"] @ aspect
Explicit declaration of joinpoints may not be as elegant as "using real AOP", but it may at least help me model joinpoints as I try to understand AOP.
I find the concepts of coexpressions and transmitting values to coexpressions ( using the "x @ c" syntax ) to be so intriguing that I am often tempted to use them when I am not sure that they are appropriate. It's just so different from any other language; I'm not sure when it's better.
Majorinc, Kazimir wrote:
Art: "how AOP might be implemented in Unicon (preferably by using existing language features rather than adding new ones? "
Procedure names are global variables, so one can assign to them during runtime, and change will be applied wherever particular procedure is used. If one want that put also counts
################################## global original_put, put_counter procedure new_put(a,b) { /put_counter:=0; put_counter }+:=1 original_put(a,b) end
# somewhere in program
original_put:=put ... put:=new_put #or even put:=?[original_put,new_put]
Technique is, of course, well known and discussed for long time, just maybe it is not noted that it is recently called AOP; this one even dynamical, one can chose which aspect to use (or not) during runtime.
----
Kazimir Majorinc, Zagreb, Croatia
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
