FAQ
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

Search Discussions

  • Trent Curry at Aug 22, 2003 at 11:21 pm
    Wow someone actually uses this group!

    --
    Stan
  • Lothar Scholz at Aug 23, 2003 at 12:59 pm

    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.
  • Bruce Williams at Aug 24, 2003 at 8:14 am

    -----Original Message-----
    From: python-list-admin at python.org
    [mailto:python-list-admin at python.org] On Behalf Of Lothar Scholz
    Sent: Saturday, August 23, 2003 5:59 AM
    To: python-list at python.org
    Subject: Re: Aspect oriented Everything?

    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
    Isn't the classic example for Aspect Oriented language extensions security
    issues that cross class boundaries and are -not-object-oriented- by nature?
    I am not agreeing with this, but that is an example the proponents seem to
    use regularly.


    Bruce Williams

    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.
    --
    http://mail.python.org/mailman/listinfo/python-list
  • Hung Jung Lu at Aug 27, 2003 at 2:57 am
    Steven Ketcham <stedak at charter.net> 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
  • Chris Reedy at Aug 27, 2003 at 2:52 pm
    If you're interested in this topic, you might check out the work of
    Harold Ossher at IBM on "Multi-Dimensional Separation of Concerns". (I
    can provide a detailed reference if you email me.) Even though he's
    become part of the AOP community, I always found the arguments in his
    original papers more compelling than more current AOP work.

    Chris

    Hung Jung Lu wrote:
    Steven Ketcham <stedak at charter.net> 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. [snip]
    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 at Aug 27, 2003 at 4:10 pm
    Jason Williams <jason at jasonandali.org.uk> wrote in message news:<slrnbkot3p.1d5.jason at kotu.jasonandalishouse.org.uk>...
    In article <8ef9bea6.0308261857.1b44a5b7 at posting.google.com>, 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
  • Jason Williams at Aug 27, 2003 at 4:40 pm

    In article <8ef9bea6.0308270810.7adfe408 at posting.google.com>, Hung Jung Lu wrote:
    def methodThatHasToListenForAnEvent
    listenForEvent(e) do
    # The method stuff goes here
    end
    end
    [snip]
    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 [snip
    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?
    Okay;

    module EventListenThing
    def listenForEvent(e)
    # ...
    end
    end

    class Thingy
    include EventListenThing

    def wotsit
    listen(e) do
    # ...
    end
    end
    end

    What does AOP gain over mixins?
  • Andrew Dalke at Aug 27, 2003 at 5:01 pm

    Hung Jung Lu:
    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?
    What about
    class RegisterFunc(object):
    ... def __init__(self, f):
    ... self.f = f
    ... def __get__(self, obj, type = None):
    ... return RegisterCall(self.f, obj)
    ...
    class RegisterCall(object):
    ... def __init__(self, f, obj):
    ... self.f = f
    ... self.obj = obj
    ... def __call__(self, *args, **kwargs):
    ... register()
    ... try:
    ... self.f(self.obj, *args, **kwargs)
    ... finally:
    ... deregister()
    ...
    def register():
    ... print "Register"
    ...
    def deregister():
    ... print "Deregister"
    ...
    class Spam(object):
    ... def spam(self):
    ... print "I've been spammed!"
    ... spam = RegisterFunc(spam)
    ...
    Spam.spam()
    Register
    I've been spammed!
    Deregister
    >>>

    If you don't have AOP, you would have to manually modify each class into: ...
    Notice that OOP or class
    inheritance will not allow you to factor out these types of
    "horizontal common code spots".
    Hmm. Given that, is what I'm doing above not OO programming?
    You can derive from it, and because the methods are not changed
    once the class is defined, I event get the proper behaviour that
    the childrens' behaviour is more restrictive than the parent's.

    (I point this out because pre-2.3 I would have used __getattr__
    hooks to make a wrapper around the whole class, rather than
    a per-method one like I did here.)
    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: ...
    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.
    For this I would usually use a mixin or just call a function. Or
    change it so there are functions which can each modify a state,
    as in

    class Modifier:
    def between_1_and_2(self, state):
    ..
    def between_2_and_3(self, state):
    ..

    class FixedRateModifier(Modifier):
    ...
    class GovernmentBondModifier(Modifier):
    ...


    def f(arg1, arg2, arg3, ...):
    modifiers = [FixedRateModifier(), GovernmentBondModifier()]
    state = State(arg1, arg2, arg3)
    do_step1_calculations(state)

    for m in modifiers:
    m.between_1_and_2(state)

    self.do_step2_calculations(state)

    for m in modifiers:
    m.between_2_and_3(state)

    ...

    Is this a hand-written way of doing AOP? (I wouldn't be surprised.
    I didn't understand OO until I handwrote a system using typedefs
    and lots of function pointers.)

    Clearly inheritance
    is not the way to implement properties/features like these ones. OOP
    just cannot solve the problem.
    Agreed about the inheritance part. Disagree that there are non-AOP
    ways to address it.

    Andrew
    dalke at dalkescientific.com
  • Hung Jung Lu at Aug 28, 2003 at 3:25 am
    Ben Giddings <ben at thingmagic.com> wrote in message news:<3F4CDC9F.1050100 at thingmagic.com>...
    Unless I'm missing something, using blocks in Ruby gets around most of this:
    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
    ...
    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?
    No. Other people may differ, but to me, as long as the code is
    factorized, it's good.

    (1) AOP came from the camps of strongly-typed languages, principally
    Java. In Ruby and Python there are lot of devices for manipulating
    code. Ruby has code blocks, in Python you can pass namespaces and use
    exec, or compose multiple functions (in the sense of function
    composition as in algebra) to achieve same effect as the before-,
    after-, around- advices of AOP. All achieving the goals of AOP in this
    example. There are many ways to achieve the same thing.

    (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.

    (3) To me, if the code is factorized, it's good enough. However, if
    you have existing code and if you want to add aspects to it, you may
    wish to modify the underlying language to expose more "hooks" and
    allow more meta-programming features, so that minimal or no changes
    need to be done on your existing code. For instance, in your example
    above, if you want to add/remove the "helper do... end" wrapper-around
    in f2(), you would have to go to the original source code to
    add/remove it. At least in AspectJ, the idea is NOT to modify the
    original source code, so that you can implement the aspects externally
    to the class. (see for instance a Java example in
    http://www.voelter.de/data/articles/aop/aop.html)

    On the various techniques for achieving AOP (separation of concerns),
    there is a paper ftp://ftp.ccs.neu.edu/pub/people/lieber/crista/techrep95/separation.pdf
    that mentions the following three techniques: (a) meta-level
    programming, (b) adaptive (pattern-oriented) programming, (c) use of
    composition filters. In short, there is more than one way to do it. :)

    Hung Jung
  • David Abrahams at Aug 28, 2003 at 7:33 am

    hungjunglu at yahoo.com (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
  • Evan Simpson at Aug 27, 2003 at 4:44 pm
    Based on your explanation, it seems to me that one way to view AOP is as
    a way of defining "method templates" that can be applied from "outside"
    of the code that defines the methods via pattern-matching on classes.

    There have been quite a few times when I've found myself wanting to be
    able to abstract a pattern across function or method definitions, but
    where the shared operations involve so much local state that refactoring
    into explicit subfunctions is too awkward. Usually I end up with
    cut-and-paste code or a bulky class-based solution.

    Cheers,

    Evan @ 4-am
  • Andrew Dalke at Aug 27, 2003 at 5:02 pm

    Hung Jung Lu:
    (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.)
    But then there's wavelets.

    :)

    Andrew
    dalke at dalkescientific.com
  • Robert Will at Aug 31, 2003 at 3:01 pm
    llothar at web.de (Lothar Scholz) wrote in message news:<6ee58e07.0308230459.24f53b64 at posting.google.com>...
    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.
    I see, you watched the trend the closely. Incidentally I have the
    same opinion, except that I don't consider their dysfunctional
    examples as proof of concepts.
  • Will Stuyvesant at Aug 23, 2003 at 7:03 pm

    [letterbox1001 at hotmail.com (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.
  • Michael Pyle at Aug 27, 2003 at 2:22 pm
    I hear what your saying but have to admit it's not sinking in very well. Can
    you provide a simple concrete example contrasting an OOP approach to an AOP
    with code snipets?

    --Mike Pyle
    -----Original Message-----
    From: hungjunglu at yahoo.com [mailto:hungjunglu at yahoo.com]
    Sent: Tuesday, August 26, 2003 7:58 PM
    To: python-list at python.org
    Subject: Re: Aspect oriented Everything?

    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
    --
    http://mail.python.org/mailman/listinfo/python-list
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.python.org/pipermail/python-list/attachments/20030827/d41ba6f3/attachment.html
  • Sascha Dördelmann at Aug 27, 2003 at 8:00 pm

    letterbox1001 at hotmail.com (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
  • Clifford Heath at Sep 1, 2003 at 3:21 am

    New_aspect wrote:
    What I want to know is,if anybody on a
    commercial scale is using AOSD to develop commercial products?
    I have been using aspect oriented design techniques since 1992,
    when I invented a name "contextual extension" for a feature that
    occurred naturally in a data definition language I had designed
    in 1983. Needless to say, the term "aspect oriented" wasn't then
    current :-).

    I introduced hierarchical aspect-oriented design to ManageSoft last
    year, and we are finding my hierarchical approach (which extends and
    generalises most of the current AOSD state-of-the-art) helps considerably
    in the design and requirements phases - because it gives a better
    framework for SOC. So yes, it's fair to say that AO design *is* being
    used in a >1MLOC commercial product, which spans C++, Java, C# and Perl
    as well as a number of proprietry domain-specific languages (for errors,
    tracing, configuration variables, etc).

    I should say that our aspect orientation goes far beyond its traditional
    application to "infrastructure" aspects like logging etc (though we have
    identified and use over 80 different infrastructure aspects). For example,
    the ManageSoft product distributes software packages down a distribution
    hierarchy. Each distribution server has a basic object type which is
    extended with several facets. The Packages facet details which packages
    are or should be on each server. The Hierarchy facet details where this
    server lives in the hierarchy, and the Configuration facet details the
    configuration state of each server. These facets are *independent* of
    each other, yet belong to the same object - each reflects where the object
    cuts across a particular aspect. It's a kind of polymorphism, so not really
    that new.

    I think that the use of Aspect Oriented techniques beyond the infrastructure
    layers is the main area for adding value. As has been noted, infrastructure
    requirements should be built into the basic language, or added through
    low-impact libraries - Ruby allows (though by manual construction) the best
    of both worlds in this regard.

    We are using Ruby for a multiple tier generator based on an XML database
    schema language. This generator makes use of Ruby's mixins and the
    "extend" method to implement "facet realisation" - dynamic extension
    of base classes to allow them to serve in a particular context.
    This is primitive aspect oriented programming, and works well.

    The generator produces data tiers in C# and C++, web services definitions
    and implementations, web-service client proxy stubs that implement location-
    and version-transparency, as well as high-quality printed documentation, SQL
    DDL and stored procedures, and will be extended to cover test cases, schema
    migration and perhaps user interfaces (in C#). Despite our database only
    containing 58 tables, the 3KLOC generator reads a 1.2KLOC schema file
    and generates over 50KL of high-quality, formatted, readable, commented
    code. If I was a contractor it would be a license to print money. Of all
    langages I've learnt or created, implementing this generator in Ruby using
    aspect-oriented techniques is the only way to have kept it down to its current
    3KLOC - and most of that code is templates!
    Is it the fact that AOP is new and, for most, confusing
    Maybe. Although it is somewhat difficult to grapple with, the intrinsic
    concepts are much simpler than current implementations indicate. AspectJ
    had to integrate with Java, so had to multiply the basic concepts, and
    had to live within the traditional source-file idiom. AOD tools *must*
    support dynamic view synthesis, allowing visualisation of the system in
    both composed and partly-composed form. I'm not aware of a tool that
    does that. Aspect oriented design requires a visual language for presenting
    designs. Some work has been done on adding AOD features to UML, but
    basically it's difficult because AOD is used to implement multi-dimensional
    designs - which can't easily be flattened to any 2-D language. I think
    that the only hope there is for a 1-D (traditional text-based) language
    which is supported by powerful graphical tools which allow filtering the
    aspects exposed in dynamic views.

    A true AOD language (as opposed to a hack preprocessor added to an
    existing language) would also support dynamic extension (which I term
    facet realisation). We do that in Ruby with mixins and extend(), but
    it's a bit too "manual".
    Is an Open Source development ever going to gain the trust of industry?
    What on earth has that got to do with AOP?
    What are the main features that may lead to AOSD adoption?
    Proper filtering aspect browsers in an IDE for a naturally aspect-oriented
    language. None of which currently exist, as far as I'm aware.
    Is AOP the next step on from OOP?
    Perhaps, if the tool support is provided.
    Is it another chance for some of the lesser
    utilised languages to step up to Java and C++?
    No. I don't believe that AOD can be adequately justified when implemented
    as an extension to either C++ or Java. AFAIK, there is no viable candidate
    for the title of the first viable aspect-oriented language.

    I meant to publish a bunch of writings and tools at my nascent domain
    www.aspectdesign.org, but my employer is not forthcoming with an IP
    disclaimer to publish tools so the domain lies dormant and the tools
    unwritten. Sigh. I honestly believe these tools must be open source.
    I've previously tried to found a business based on simple, general
    powerful software tools and languages, and have become convinced that
    commercial survival is only possible with limited-purpose tools.
    Proprietry standards for basic technologies are doomed.

    Clifford Heath, cjh at spam-me-rotten.managesoft.com - you work it out.
  • Anton Vredegoor at Sep 1, 2003 at 9:30 am
    Clifford Heath wrote:

    <snip>
    Proprietry standards for basic technologies are doomed.
    Right. However the previous long piece of text lead me to read this
    the exact opposite way of what is written above at first. Is this a
    perceptual illusion trick or is it my bad? Never mind, all's well that
    ends well :-)

    Anton
  • Clifford Heath at Sep 2, 2003 at 11:30 pm

    Anton Vredegoor wrote:
    Proprietry standards for basic technologies are doomed.
    Right. However the previous long piece of text lead me to read this
    the exact opposite way of what is written above at first.
    :-). I believe in tools, and on re-reading I guess you thought I was
    about to start spruiking some tool, and I *am* invoking tool-makers
    to rise to the challenge. OTOH - they shouldn't expect money for it,
    only glory :-).

    Clifford.

Related Discussions

People

Translate

site design / logo © 2022 Grokbase