Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > AOP bigger picture

Reply
Thread Tools

AOP bigger picture

 
 
trans. (T. Onoma)
Guest
Posts: n/a
 
      09-24-2004
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.
/ \ http://www.velocityreviews.com/forums/(E-Mail Removed)

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



 
Reply With Quote
 
 
 
 
trans. (T. Onoma)
Guest
Posts: n/a
 
      09-24-2004
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.
/ \ (E-Mail Removed)

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



 
Reply With Quote
 
 
 
 
Jason Voegele
Guest
Posts: n/a
 
      09-24-2004
T. Onoma said:
> OOPS!!! Very Sorry, wrong list!


It's too bad that you think so. I was very interested in discussion about
the points you brought up and the future of AOP in Ruby.

--
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life's externals may be transformed
or recombined. But it's smaller than we think."
-- Gene Wolfe, The Book of the Long Sun





 
Reply With Quote
 
trans. (T. Onoma)
Guest
Posts: n/a
 
      09-24-2004
On Friday 24 September 2004 02:09 pm, Jason Voegele wrote:
> T. Onoma said:
> > OOPS!!! Very Sorry, wrong list!

>
> It's too bad that you think so. I was very interested in discussion about
> the points you brought up and the future of AOP in Ruby.


Well then, feel free! Always interrested in other's insights. You can do so
here or over on other other list:

https://lists.berlios.de/mailman/listinfo/suby-ruby

Which ever you'd prefer.

T.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Apple's nitwit pundits miss the bigger picture RichA Digital Photography 36 03-31-2011 02:15 AM
Apple's nitwit pundits miss the bigger picture RichA Digital Photography 0 03-02-2011 04:00 PM
Bigger picture with Nikon D40 (x) Sosumi Digital Photography 3 11-12-2007 03:37 PM
Serialization file getting bigger and bigger on the same object yancheng.cheok@gmail.com Java 2 04-10-2007 09:26 AM
App getting bigger and bigger Yannick Turgeon Perl Misc 1 10-14-2003 04:47 AM



Advertisments