T
trans. (T. Onoma)
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 address removed)
I don't give a damn for a man that can only spell a word one way.
-Mark Twain
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 address removed)
I don't give a damn for a man that can only spell a word one way.
-Mark Twain