[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    AOP bigger picture
From:       "trans.  (T. Onoma)" <transami () runbox ! com>
Date:       2004-09-24 17:59:49
Message-ID: 200409241359.40245.transami () runbox ! com
[Download RAW message or body]

Here's a brief report of some my AOP research[1] related to the "bigger 
picture" of conditionally crosscutting multiple classes, methods, etc. 


I. Compile vs. Event

There appears to be two extremes in the approaches. On the one end there is 
purely static compile time weaving. On the other is fully dynamic event 
driven interception.

The first is really just 'aspect oriented' code generation. It does the job 
but cannot be changed "on-the-fly" by the executing program. This isn't 
necessarily bad, since the aspects themselves can be designed with embedded 
if-else conditions to vary execution as needed; you just won't be able to 
vary it "externally" ( unless of course you aspect your aspects and 
recompile ;)

The other end, might even called its own programming paradigm: Event Oriented 
Programming, or EOP, (also known as EAOP). Ruby actually has capabilities in 
this regard with Kernel#set_trace_func. I was playing with that today to see 
how much I could get it to do. And I actually have a near working 
implementation along the lines Florain's. Unfortunately, set_trace_func has 
two limitations that make it unattainable. 1) It does not pass the arguments 
of the current method, and 2) it does not allow the current method execution 
to be shortcutted (i.e. return without execution of a call). If these points 
could be dealt with, this would be a very powerful means of aspecting. It can 
be used to intercept almost anything: class definitions, internal interpretor 
calls, program line numbers, etc. --a very fine comb. Of course the VERY BIG 
problem with this is efficiency. It easily slows program execution down 100 
fold or more.

The optimum solution would therefore seem to be somewhere in the middle of 
these two extremes. Or at least that's how it seems. On closer inspection, 
there may not be all that much difference between the two. If static aspects 
get complex enough, the code will have many "if this then that elsif this 
else that", etc. An which point all those if-then start to wiegh on execution 
speed much like an event based solutions. But the event based solution will 
still be slower b/c static aspects won't run an if-clause for every possible 
piece of code excution like EOP will. But again with a little tweaking of the 
EOP model, such that set_trace_func is omptimized to turn on and off when 
required, that difference is further eroded, such that it would probably be 
nearly negligable.

But all this is rather academic since Ruby is quite dynamic, and as such we 
can find a nice cushy place in the middle that should suit us just fine.


II. Literal vs. Semantic

The other thing I've noticed about designs in this larger picture area is a 
division between "literal pointcuts" and "semantic setpoints". Aspect/J is 
the prime example of the former, it defines pointcuts based on explicit code 
criteria. The later, by contrast, adds another layer of abstraction --and 
then defines setpoints based on that abstraction. Method tags are a very 
simple, but good, example of this; it can also get very complex using things 
like OWL[2].

My feeling here, is again to find a cushy place in the middle.


III. Conclusion

Now on both points, when I say middle, I don't necessarily mean a single 
middle of the road tool, but rather, perhaps the ideal is to offer a few 
different levels of possible exploitation. The 'cut' is a perfect example of 
a low level solution. We just need to offer a higher level one to complement 
it. We could also possibly offer a nicer API plus optimizations to an 
improved set_trace_func for when the fine comb is needed. One upshot of this 
may be a universal "CodePoint" object for use by set_trace_func, caller_stack 
for caller, and our own AOP methods. That would make for a nice "coming 
together" of various parts of Ruby under the AOP démarche.

Likewise method tags add simple semantics, which is good to have. And we may 
go further and add an additional, more systematic, way to relate classes to 
each other in some form of Ruby dialect -- something like a simplified OWL 
via Ruby constructs.

Right now, I'm thinking that offereing a few different, but very well 
integrated techinques may be much better then trying to kill every bird with 
a single stone.

Thoughts?

T.

[1] This page was very helpful: http://aosd.net/technology/research.php
[2] OWL: http://www.w3.org/TR/owl-features/

-- 
( o _  カラチ
 //    trans.
/ \    transami@runbox.com

I don't give a damn for a man that can only spell a word one way.
-Mark Twain


[prev in list] [next in list] [prev in thread] [next in thread]