AOP bigger picture

Discussion in 'Ruby' started by trans. (T. Onoma), Sep 24, 2004.

  1. 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.
    / \

    I don't give a damn for a man that can only spell a word one way.
    -Mark Twain
     
    trans. (T. Onoma), Sep 24, 2004
    #1
    1. Advertising

  2. 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.
    / \

    I don't give a damn for a man that can only spell a word one way.
    -Mark Twain
     
    trans. (T. Onoma), Sep 24, 2004
    #2
    1. Advertising

  3. 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
     
    Jason Voegele, Sep 24, 2004
    #3
  4. 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.
     
    trans. (T. Onoma), Sep 24, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anu Raj Pradhan
    Replies:
    0
    Views:
    381
    Anu Raj Pradhan
    Jul 14, 2003
  2. X_AWemner_X

    XDoclet, JBOSS-AOP Example3

    X_AWemner_X, Aug 7, 2003, in forum: Java
    Replies:
    0
    Views:
    695
    X_AWemner_X
    Aug 7, 2003
  3. Replies:
    2
    Views:
    787
    Filip Larsen
    Apr 10, 2007
  4. Yannick Turgeon

    App getting bigger and bigger

    Yannick Turgeon, Oct 13, 2003, in forum: Perl Misc
    Replies:
    1
    Views:
    142
    Yannick Turgeon
    Oct 14, 2003
  5. Replies:
    8
    Views:
    1,287
    Mick White
    Apr 19, 2005
Loading...

Share This Page