OOPS!!!  Very Sorry, wrong list!

On Friday 24 September 2004 01:59 pm, trans.  (T. Onoma) wrote:
> 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