Aspect oriented Everything?

Discussion in 'Ruby' started by New_aspect, Aug 22, 2003.

  1. New_aspect

    New_aspect Guest

    Hello,

    Aspect oriented Software development seems to be expanding in the
    popular vision of developers, with more and more IDE 'add-ons' and
    even more specialized tools,Jboss etc.
    I've seen more and more languages integrate AOP,AspectJ (Java),
    AspectR(Ruby)etc.Aspect oriented does seem to be the place to go from
    a developer standpoint.What I want to know is,if anybody on a
    commercial scale is using AOSD to develop commercial products? Is an
    Open Source development ever going to gain the trust of industry? It
    may be ok for personal projects and other Open Source material but
    will your bank ever accept it? Is it the fact that AOP is new and, for
    most,confusing or is it the fact that AOP has developed in the
    environment it has.i.e Open Source,that may dissuade commercial
    development shops from accepting AOP.

    What are the main features that may lead to AOSD adoption? Is AOP the
    next step on from OOP? Is it another chance for some of the lesser
    utilised languages to step up to Java and C++? Your opinions on the
    subject would be appreciated? Design features are one thing but
    widespread adoption is another, or is it?

    Anything you care to add on the subject would be appreciated on this
    short questionnaire.
    http://www.geocities.com/aspect505

    Thank you for your participation.


    Shane Hassan.


    http://www.geocities.com/aspect505
     
    New_aspect, Aug 22, 2003
    #1
    1. Advertising

  2. New_aspect

    Trent Curry Guest

    Wow someone actually uses this group!

    --
    Stan
     
    Trent Curry, Aug 23, 2003
    #2
    1. Advertising

  3. On Sat, 23 Aug 2003 08:54:04 +0900
    Mark Wilson <> wrote:
    <snip>
    > I have yet to read a description of what aspect oriented development
    > is and how one would use it, that I could understand (i.e., with a
    > code example that explains what is being done). Could someone provide
    > such a description?


    Search RAA for aspectr. I don't think it's maintained, but the code is
    interesting.
     
    Albert Wagner, Aug 23, 2003
    #3
  4. > Aspect oriented Software development seems to be expanding in the
    > popular vision of developers, with more and more IDE 'add-ons' and
    > even more specialized tools,Jboss etc.


    I'm not sure if this is a the way to go. I've only seen proof of
    concept but no real use. But only in the latter case you can see the
    problems.

    I don't like it because it breaks encapsulation and splitters the code
    over a few files. Maybe that can be solved with new kind of editors
    but it is much more easy to result in a big confusion.

    The most important use cases that i've seen so far are:

    - Logging facilities
    - Debugging code
    - Pre/Postconditions
    - Threading synchronization

    1+2+3 can be embedded in a language. This is already done in Eiffel.
    I don't know if i really want to see something as difficult as
    "threading synchronization" as an aspect.
     
    Lothar Scholz, Aug 23, 2003
    #4
  5. > [ (New_aspect)]
    > Aspect oriented Software development seems to be expanding ...
    > ...some of the lesser
    > utilised languages to step up to Java and C++?


    How about stepping from Java or C++. AOP is just a contrived way to
    get around the static typing restrictions that Java and C++ have. You
    need Python.

    --
    I fear explanations explanatory of things explained.
     
    Will Stuyvesant, Aug 23, 2003
    #5
  6. We make our new hires give a brief presentaion on some technology as part
    of the interview process. In our last hiring binge we used AOP as the
    principle topic. It lets us see the communication skills of the prospect
    and it also allows us a glimpse into areas none of us have time to pursue.

    AOP was very difficult to explain, debug and implement. It did not
    obviously replace any of our current procedures and at best it was
    perceived as very heavy-weight. The conclusion on AOP was that it was a
    neat concept but there was no immediate benefit for using it.

    Since then I have seen a couple of articles in Software Development
    Magazine (online version) suggesting that AOP is no longer as "cool" as it
    used to be. With OOP it is fairly obvious that it reduces the complexity of
    the software process and if used correctly it is fairly easy to explain.
    With AOP there is no single, simple overview of the technology.

    On Sat, 23 Aug 2003 22:00:22 +0900, Lothar Scholz <> wrote:

    >> Aspect oriented Software development seems to be expanding in the
    >> popular vision of developers, with more and more IDE 'add-ons' and
    >> even more specialized tools,Jboss etc.

    >
    > I'm not sure if this is a the way to go. I've only seen proof of
    > concept but no real use. But only in the latter case you can see the
    > problems.
    >
    > I don't like it because it breaks encapsulation and splitters the code
    > over a few files. Maybe that can be solved with new kind of editors
    > but it is much more easy to result in a big confusion.
    >
    > The most important use cases that i've seen so far are:
    >
    > - Logging facilities
    > - Debugging code
    > - Pre/Postconditions
    > - Threading synchronization
    >
    > 1+2+3 can be embedded in a language. This is already done in Eiffel.
    > I don't know if i really want to see something as difficult as
    > "threading synchronization" as an aspect.
    >
    >




    --
     
    Steven Ketcham, Aug 23, 2003
    #6
  7. New_aspect

    Hung Jung Lu Guest

    Steven Ketcham <> wrote in message
    > AOP was very difficult to explain, debug and implement. It did not
    > obviously replace any of our current procedures and at best it was
    > perceived as very heavy-weight. The conclusion on AOP was that it was a
    > neat concept but there was no immediate benefit for using it.
    >
    > On Sat, 23 Aug 2003 22:00:22 +0900, Lothar Scholz <> wrote:
    > > I don't like it because it breaks encapsulation and splitters the code
    > > over a few files. Maybe that can be solved with new kind of editors
    > > but it is much more easy to result in a big confusion.


    AOP is the latest effort in code factorization. Code factorization
    started with the goto statement, then loops, then functions, then
    classes and methods. And now, AOP.

    If you write programs in OOP long enough, you will realize that there
    are code spots that are not factorized. For example, you register to a
    event listener at the beginning and de-register at the end of a
    method. If you find yourself writing very similar codes in various
    classes or methods all over places, you are not factoring your code
    efficiently. It's not your fault, it's just that OOP cannot do certain
    types of code factorization.

    Before having loops, a repetitive task may look like

    x = x + 1
    x = x + 1
    x = x + 1

    But when you have loops, you can factor the three lines of code into

    for i in range(3):
    x = x + 1

    Similarly, before object-oriented programming, you have data structure
    that are very similar, say, A and B, A has (color, shape) and B has
    (color, shape, weight), with OOP you can use inheritance, and factor
    out the common code.

    If we view OOP and inheritance as a vertical dimension in code
    factorization, AOP would be a new horizontal dimension in code
    factorization. Hence, people use terms like "aspect weaving".

    Some people don't like AOP because it violates encapsulation in the
    vertical dimension. But this way of thinking is kind of, erh,
    unidimensional. Because conversely, a program that is built from
    purely AOP is encapsulated in its own aspect dimension, and the usage
    of OOP in that case would violate the encapsulation in the horizontal
    dimension. The fact is, both factorizations are needed in the real
    world. Aspect-oriented coding and object-oriented coding are like the
    conjugate variables in quantum mechanics, whether you use one picture
    or the other, at the end of the day they are equivalent, but in some
    circumstances it's better to use one than the other. (If you know
    Fourier transform, you know what I mean. A localized wave packet in
    time necessarily means a spread-out packet in frequency, and
    vice-versa. You can't have encapsulation both ways.)

    regards,

    Hung Jung
     
    Hung Jung Lu, Aug 27, 2003
    #7
  8. On Wed, 27 Aug 2003 12:09:46 +0900
    (Hung Jung Lu) wrote:
    <snip>

    Great post. This explains the purpose of AOP better than I have ever
    seen it expressed. Thank you.
     
    Albert Wagner, Aug 27, 2003
    #8
  9. New_aspect

    mgarriss Guest

    Hung Jung Lu wrote:
    <snip>

    Thanks for the post Hung, very interesting. Could you recommend a link
    or two for more info?

    Michael
     
    mgarriss, Aug 27, 2003
    #9
  10. New_aspect

    Hung Jung Lu Guest

    Jason Williams <> wrote in message news:<>...
    > In article <>, Hung Jung Lu wrote:
    > > If you write programs in OOP long enough, you will realize that there
    > > are code spots that are not factorized. For example, you register to a
    > > event listener at the beginning and de-register at the end of a
    > > method.

    >
    > Eh? What's wrong with;
    >
    > def methodThatHasToListenForAnEvent
    > listenForEvent(e) do
    > # The method stuff goes here
    > end
    > end


    The question is: are there code spots that are not factored? If you
    have ONE single class that has to implement the before, around, or
    after methods, sure, nothing wrong with what you have said. But, if
    you have

    class A:
    def f1():
    register()
    ...
    deregister()
    class B:
    def f2():
    register()
    ...
    deregister()
    class C:
    def f3():
    register()
    ...
    deregister()

    You start to ask your self: how come the register() deregister() parts
    are not factor out? How can I factor out these parts of code?

    Why do you want to factor them out? You may ask. Because sometimes
    later, you may realize that, heh, actually you want to do one more
    thing before calling f1() f2() f3(): at beginning of the calls you
    want to log the method call. If you don't have AOP, you would have to
    manually modify each class into:

    class A:
    def f1():
    log()
    register()
    ... non-factorizable code specific to f1
    deregister()
    class B:
    def f2():
    log()
    register()
    ... non-factorizable code specific to f2
    deregister()
    class C:
    def f3():
    log()
    register()
    ... non-factorizable code specific to f3
    deregister()

    And later, you find out that you want to catch an certain type of
    exception and respond properly, without AOP, you go back to your code
    and write something like:

    class A:
    def f1():
    try:
    log()
    register()
    ... non-factorizable code specific to f1
    deregister()
    except:
    ...
    class B:
    def f2():
    try:
    log()
    register()
    ... non-factorizable code specific to f2
    deregister()
    except:
    ...
    class C:
    def f3():
    try:
    log()
    register()
    ... non-factorizable code specific to f3
    deregister()
    except:
    ...

    And then you realize that, oh, when the exception happens, you need to
    do some clean up, then you go back to your code and do

    class A:
    def f1():
    try:
    log()
    register()
    ... non-factorizable code specific to f1
    deregister()
    except:
    ...
    finally:
    ...
    class B:
    def f2():
    try:
    log()
    ... non-factorizable code specific to f2
    ...
    deregister()
    except:
    ...
    finally:
    ...
    class C:
    def f3():
    try:
    log()
    register()
    ... non-factorizable code specific to f3
    deregister()
    except:
    ...
    finally:
    ...

    And then, someone tells you that they want to know the time spent in
    these methods, so you do:

    class A:
    def f1():
    start_timer()
    try:
    log()
    register()
    ... non-factorizable code specific to f1
    deregister()
    except:
    ...
    finally:
    ...
    end_timer()
    class B:
    def f2():
    start_timer()
    try:
    log()
    ... non-factorizable code specific to f2
    ...
    deregister()
    except:
    ...
    finally:
    ...
    end_timer()
    class C:
    def f3():
    start_timer()
    try:
    log()
    register()
    ... non-factorizable code specific to f3
    deregister()
    except:
    ...
    finally:
    ...
    end_timer()

    And it is at this point that you start to wonder, man, it's tedious
    and error-prone trying to do the something to all the classes that
    share similar functionalities. And at the moment, you start to wonder
    whether you can factor out the similarities. Notice that OOP or class
    inheritance will not allow you to factor out these types of
    "horizontal common code spots". A way to see it is to have three
    sheets of paper, and you write the code of class A, B, C on each
    sheet, and stack the three sheets together. The common areas that
    overlap are in a horizontal direction. This type of horitontal
    factorization is what AOP is all about. Once you factor out the common
    parts, you can modify the code spot just once, and it will be applied
    automatically to all your classes.

    To my, horizontal factorization is what AOP is all about. It goes
    beyond the before-, around-, after- hooks. I've written codes where I
    have many if statements in a base class method:

    def f():
    #--------------- step 1 during calculation
    code shared under all circumstances
    #--------------- step 1 during calculation
    if self.has_fixed_rate():
    ....
    else:
    ....
    if self.is_government_bond():
    ....
    else:
    ....
    if self.is_domestic():
    ....
    else:
    ....
    #--------------- step 2 during calculation
    code shared under all circumstances
    #--------------- step 3 during calculation
    if self.has_fixed_rate():
    ....
    else:
    ....
    if self.is_domestic():
    ....
    else:
    ....
    #--------------- step 4 during calculation
    code shared under all circumstances
    #--------------- step 5 during calculation
    if self.is_domestic():
    ....
    else:
    ....
    if self.is_government_bond():
    ....
    else:
    ....

    After writing so many if...else... statement, you start to wonder: can
    I factor out these if...else... statements? One way is to use OOP and
    subclasses to encapsulate the is_domestic(), is_government_bond(),
    has_fixed_rate() features, (e.g: have a subclasses like
    domestic_fixed_rate_government_bond
    foreign_variable_rate_corporate_bond, etc.), but in OOP you will find
    out that common steps 1,2,4 will not be factored out, and that when
    you need to change the code in the common steps, you need to change in
    all subclasses, which is tedious and error-prone. Worse, with 3
    features you have a combination of 8 subclasses, and if one day you
    include one more feature, you will have 16 subclasses. Are you going
    to change the code manually in 16, 32, 64 classes? Clearly inheritance
    is not the way to implement properties/features like these ones. OOP
    just cannot solve the problem.

    It is only when you run into this kind of situations, that you start
    to think about code factorization in a different dimension.

    AOP is a really need. I would agree that it is still an immature field
    of research. But people really need it.

    Hung Jung
     
    Hung Jung Lu, Aug 27, 2003
    #10
  11. New_aspect

    Ben Giddings Guest

    Unless I'm missing something, using blocks in Ruby gets around most of this:

    Hung Jung Lu wrote:
    > class A:
    > def f1():
    > start_timer()
    > try:
    > log()
    > register()
    > ... non-factorizable code specific to f1
    > deregister()
    > except:
    > ...
    > finally:
    > ...
    > end_timer()


    Instead of "... non-factorizable code specific to f1", just yield to the
    block given to the function. Tada! Or, for a more concrete example:

    module HelperMixin
    def helper
    start_timer
    begin
    log
    register
    yield
    deregister
    rescue
    ...
    ensure
    ...
    end
    end_timer
    end
    end

    class A
    include HelperMixin

    def f1
    helper do
    ... code specific to f1
    end
    end

    def f2
    helper do
    ... code specific to f2
    end
    end
    end

    Did I miss the point here?

    Ben
     
    Ben Giddings, Aug 27, 2003
    #11
  12. New_aspect

    Chris Morris Guest


    > module HelperMixin
    > def helper
    > start_timer
    > begin
    > log
    > register
    > yield
    > deregister
    > rescue
    > ...
    > ensure
    > ...
    > end
    > end_timer
    > end
    > end
    >
    > class A
    > include HelperMixin
    >
    > def f1
    > helper do
    > ... code specific to f1
    > end
    > end
    >
    > def f2
    > helper do
    > ... code specific to f2
    > end
    > end
    > end
    >
    > Did I miss the point here?


    I think the AOP answer is that, given f1..f 16, you still have 16 places
    to touch in case anything changes with

    helper do
    end

    (like maybe helper in the future needs to now pass a var back in the
    yield call:

    helper do |x|
    end)

    A proper AOP solution would allow you to touch one spot and have it go
    into effect in f1..f16, vs. having to touch all 16 spots.

    Granted, your mixin should greatly reduce the chances of having to touch
    f1..f16, but AOP (AFAIK) seeks to eliminate the need to ever touch f1..f16.

    --

    Chris
    http://clabs.org/blogki
     
    Chris Morris, Aug 27, 2003
    #12
  13. New_aspect

    Dave Brown Guest

    In article <>,
    Albert Wagner <> wrote:
    : On Wed, 27 Aug 2003 12:09:46 +0900
    : (Hung Jung Lu) wrote:
    : <snip>
    :
    : Great post. This explains the purpose of AOP better than I have ever
    : seen it expressed. Thank you.

    Shame about the lack of any kind of real example.

    --Dave
    --
    "But you've got to hand it to IBM, they know how to design
    hardware. The servers all had handles to pick them up and throw
    them out of the window...."
    -- Juergen Nieveler
     
    Dave Brown, Aug 27, 2003
    #13
  14. (New_aspect) wrote:
    > What I want to know is,if anybody on a
    > commercial scale is using AOSD to develop commercial products?


    I know about AOP for quite a while now but I've actually never used it
    in a commercial product.

    One reason I can offer you is, that it was always easy to get around
    using it. You know most of the "vertical" and "horizontal" needs from
    the beginning of the project and are free to include them in your UML
    model.

    One strategy to get around AOP at design time ist multiple inheritance
    (MI). Even if the language doesn't support MI directly there are many
    ways to implement an UML model which includes MI. Other strategies
    include the visitor pattern or some other form of delegation to
    specialized objects.

    There are some things which could make AOP more attractive:
    - discussions like this one
    - integration in some language would of course make some people use it
    (but who would use this brand new language?)
    - find a "killer app" (e. g. show that it's better to use AOP to
    profile
    than to use the standard profiling tools)
    - make it either as simple as possible or very difficult but with
    enormous power
    - build a refactoring browser which refactors aspects to where they
    belong
    ;-)

    Generic programming is gaining more and more attention in the world of
    statically typed languages. AOP could be part of that. On the other
    hand it's a lot easier to implement AOP in a dynamic language like
    Ruby. And as people like the nature of their favorite language, they
    might like the dynamic aspect of AOP, too.

    Cheers
    Sascha
     
    Sascha Dördelmann, Aug 27, 2003
    #14
  15. (Hung Jung Lu) writes:

    > (2) Yet another approach is using code templates, a la
    > meta-programming. There are more complicated examples, like the second
    > example in my previous posting, where it's not easily solved by one
    > single code block, nor one single MixIn, nor by function composition.
    > In that case one can assemble the code by using a template, and make
    > successive pattern substitutions depending on the properties of the
    > particular instrument. Of course, this approach is a bit beyond the
    > reach of Java/C++, and anyway the strongly-typed language people would
    > protest because your code may not have been properly verified by the
    > compiler.


    Don't lump Java and C++ together, please!

    I am currently writing a book about metaprogramming in C++, using
    (ahem) templates. I realize that you were referring to a more
    abstract concept when you wrote "template", but it's still amusing
    that the very C++ feature which implements your "template" is called
    "template". Well, maybe I need more sleep. It's amusing to me
    anyway.

    Anyway, the compile-time computational power of C++ templates goes far
    beyond simple templated code generation. In fact they have been shown
    to be Turing-complete
    (http://osl.iu.edu/~tveldhui/papers/2003/turing.pdf). And, as for
    proper code verification, template metaprogramming doesn't compromise
    type-safety.

    Regards,
    --
    Dave Abrahams
    Boost Consulting
    www.boost-consulting.com
     
    David Abrahams, Aug 28, 2003
    #15
  16. New_aspect

    Jim Weirich Guest

    On Wed, 2003-08-27 at 12:53, Chris Morris wrote:
    > I think the AOP answer is that, given f1..f 16, you still have 16 places
    > to touch in case anything changes with
    >
    > helper do
    > end
    >
    > (like maybe helper in the future needs to now pass a var back in the
    > yield call:
    >
    > helper do |x|
    > end)
    >
    > A proper AOP solution would allow you to touch one spot and have it go
    > into effect in f1..f16, vs. having to touch all 16 spots.


    Hmmm ... this is a lot like the restriction with procedural
    abstractions. If you change the function signature, then you have to
    touch each of the calling sites.

    A question regarding this particular example (ie. adding |x|): If you
    have to add a parameter like this, wouldn't you have to touch the code
    in the do/end block anyways (to take advantage of the x parameter)?

    > Granted, your mixin should greatly reduce the chances of having to touch
    > f1..f16, but AOP (AFAIK) seeks to eliminate the need to ever touch f1..f16.


    I would really like someone to work up this example with aspectr so we
    could compare the results in more detail. Any takers?

    --
    -- Jim Weirich http://onestepback.org
    -----------------------------------------------------------------
    "Beware of bugs in the above code; I have only proved it correct,
    not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
     
    Jim Weirich, Aug 28, 2003
    #16
  17. New_aspect

    Chris Morris Guest

    Jim Weirich wrote:

    >A question regarding this particular example (ie. adding |x|): If you
    >have to add a parameter like this, wouldn't you have to touch the code
    >in the do/end block anyways (to take advantage of the x parameter)?
    >

    Yeah, I thought of that in the back of my mind while writing that
    addition, but I couldn't come up with anything else -- which may simply
    mean my point isn't worth anything :)

    But, the little AOP stuff I'd seen in the past was that it allowed me to
    inject code at the f1..f16 places without having to do *anything* at
    those spots. Like -- at the beginning of every method call, log off to a
    file the name of the method being called, start a timer, yada yada.

    >I would really like someone to work up this example with aspectr so we
    >could compare the results in more detail. Any takers?
    >

    Isn't Ruby's profiler lib an example of AOP?

    --

    Chris
    http://clabs.org/blogki
     
    Chris Morris, Aug 28, 2003
    #17
  18. New_aspect

    Avi Bryant Guest

    Ben Giddings <> wrote:

    > class A
    > include HelperMixin
    >
    > def f1
    > helper do
    > ... code specific to f1
    > end
    > end
    >
    > def f2
    > helper do
    > ... code specific to f2
    > end
    > end
    > end
    >
    > Did I miss the point here?


    One of the points of AOP (that distinguishes it from, say, macros) is
    that there doesn't have to be any notation at the pointcuts themselves
    (the places where functionality is to be added); instead, they are
    specified externally (usually not individually but as some kind of
    pattern). Examples in AspectJ are often of the form "insert this code
    into every public method of package X". Not only would it be tedious
    to add in a call to packageX_public_helper in every one of those
    methods, it might not be code that you have control over. So to
    really emulate AOP in Ruby, you have to make your "helper" additions
    completely external.

    You can do this using aliasing. For example, say you had this in one
    file:

    class A
    def f1() ... end;
    def f2() ... end;
    def f3() ... end;
    end

    In a different file you could do this:

    class A
    include HelperMixin
    alias_method :f1, :eek:ld_f1
    alias_method :f2, :eek:ld_f2
    alias_method :f3, :eek:ld_f3

    def f1() helper{old_f1} end
    def f2() helper{old_f2} end
    def f3() helper{old_f3} end
    end

    Well, this file is now pure boilerplate; the obvious next step is to
    automate the aliasing and redefining. Which is pretty much exactly
    what AspectR does, IIRC.

    The code generation for this gets a little tedious, however. I
    implemented a cleaner version of this same idea in C a long time ago,
    that you can get from
    http://beta4.com/advice.c . Ideally there would be kernel support for
    "around" methods; I think Matz has expressed an interest in this in
    the past.
     
    Avi Bryant, Aug 28, 2003
    #18
  19. For what I understood so far around what aspect oriented programming would
    try to solve,
    it seems that passing blocks that you can yield and reflexion already works
    around
    those problems. I was thinking about a neat addition that would maybe offer
    another solution
    to he idea of "defining eternaly" some of the methods that should behave
    according to a pattern,
    We already have public, protected and private methods,
    why not adding a syntax which would allow us to mark a method (even putting
    it several marks)
    public, protected or private would just be a particular property that has
    been assigned to a method.
    so you could create your own marks and stating with according syntax, say
    :?private or :? (empty to unmark)
    or in this case :?red (where you define in a mixing how to reshape red or
    blue methods so as to factor code) etc..
    with this mark available in reflexion, the object at instanciation time (or
    mixing inclusion time,
    or whenever would be the best) could be aproprietely redifned including the
    opening and closing blocks of code,
    or doing pretty much anything (this could surely be useful to some other
    concepts than just aop)
    for instance, you could define a sandbox mixin which treats the methods
    marked as dangerous (or tainted)
    in a special way, or you could have a debug or profile mixin that would
    monitor or output the results of apropriately 'marked' methods .
    Oh well, it's just an idea, not a feature request :)
    (but I do think it would be nice, particularily if this mark syntax gets
    elaborated enough to have parameters and even blocks)

    cheers..

    Olivier.


    > I'd love to see Ruby's mixin concept extend around AOP -- it seems that
    > that's where some true power lies -- unifying the two dimensions back
    > into a single, multi-dimension tree structure.
    >
    > I was postulating as I went to sleep last night that if you could have a
    > new sort of Mixin that could /wrap/ code instead of implementing the
    > base, that would be best -- and some syntactic sugar is most of what's
    > needed. The rest would just be a change in the order methods are
    > resolved: aspects first, then class implementation, then mixins and up
    > the tree.
    >
    > Some hypothetical code:
    >
    > class Foo
    > include Bar # Ordinary mixin
    > aspect Baz
    > aspect Grot # "Wrap" mixin, where the code covers over
    > # existing methods, but has a keyword like "super"
    > # to easily call original implementation.
    >
    > def frob
    > puts "In frob"
    > super
    > end end
    >
    > module Bar
    > def frob
    > puts "Bar frob!"
    > end
    > end
    >
    > module Baz
    > def frob
    > puts "Before frob 2"
    > super
    > puts "After frob 2"
    > end
    > end
    >
    > module Grot
    > def frob
    > puts "Before frob 1"
    > super
    > puts "After frob 1"
    > end
    > end
    >
    > Foo.new.frob
    >
    > and the output would be:
    >
    > Before frob 1
    > Before frob 2
    > In frob
    > Bar frob
    > After frob 2
    > After frob 1
    >
    > All this would allow a very perlish-style feature of "change the input
    > instead of the algorithm if it's easier", but with a nice, modular and
    > abstract OO and Aspect-oriented way.
    >
    > I can imagine a generic Tree class [and even more useful in a less
    > dynamic language] using aspects to handle the actual concrete types of
    > tree, but have the core class just know about a generic Tree concept...
    > that's just one tiny use that I can see now.
    >
    > Ari
    >




    --
    Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
     
    Olivier Nenert, Aug 28, 2003
    #19
  20. Aredridel <> wrote in message news:<>...
    > > It is only when you run into this kind of situations, that you start
    > > to think about code factorization in a different dimension.

    >
    > Bingo, thank you, Hung Jung! That makes AOP -totally- make sense to
    > me. I realize I do it already, instinctually, usually with callbacks in
    > methods -- I'll pass self to a mixin method at the top of the method,
    > and perhaps later at the bottom, letting me use a ruby mixin as a sort
    > of kludgy AOP cutpoint.


    Callback is different. What you do is called template method pattern:
    http://patterndigest.com/patterns/TemplateMethod.html

    AOP is indeed very similar to template method. A join point is a means
    to call a hook functon where no hook function has been defined by the
    class designer. That's why AOP is said to break encapsulation. AspectJ
    replaces the hook function by something called advice which I view as
    a strategy object or functor:
    http://patterndigest.com/patterns/Strategy.html

    The whole thing together - combining template method pattern with
    strategy pattern - is very similar to the visitor pattern:
    http://patterndigest.com/patterns/Visitor.html

    So, whenever you need the same visitor on a distinct set of methods
    (the pointcuts), there you are: use AOP instead!

    Cheers
    Sascha
     
    Sascha Dördelmann, Aug 29, 2003
    #20
    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. New_aspect

    Aspect oriented Everything?

    New_aspect, Aug 22, 2003, in forum: Perl
    Replies:
    5
    Views:
    1,108
    Robert Will
    Aug 31, 2003
  2. Julia Donawald
    Replies:
    0
    Views:
    510
    Julia Donawald
    Dec 30, 2004
  3. christopher diggins

    Aspect Oriented Programming techniques

    christopher diggins, Feb 9, 2004, in forum: C++
    Replies:
    15
    Views:
    791
    Maciej Sobczak
    Feb 11, 2004
  4. Daniel Lohmann
    Replies:
    0
    Views:
    764
    Daniel Lohmann
    Feb 10, 2004
  5. New_aspect

    Aspect oriented Everything?

    New_aspect, Aug 22, 2003, in forum: Python
    Replies:
    12
    Views:
    512
    Clifford Heath
    Sep 3, 2003
Loading...

Share This Page