[aosd-discuss] Scope of AOP..

[Kevin Sullivan]

Dean,

I agree with your message. We design our code to expose certain
abstractions. Annotations, naming/coding conventions, and other tactics, in
combination with programming mechanisms such as those that AOP languages
make available, provide interesting ways to do this -- ways that can be
effective and (evidence now suggests) sound from a software engineering
perspective. It's not that one needn't anticipate and prepare code, but
rather that AOP provides interesting and possibly valuable new possibilities
and mechanisms for doing it.

As to "obliviousness," enforced openness to advising by unanticipated
clients does create additional options for changing/enhancing system
functionswithout changes to the underlying code. It's just not clear yet (at
least to me) either that the change options are the
valuable options that real-world clients will need (except in a few special
cases, such as debugging), or that the benefits of openness outweigh the
long-term costs of permitting all sorts of non-modular task and structural
dependences to develop.

Kevin

On 4/8/06, Dean Wampler <dean at aspectprogramming.com> wrote:
>
> Pascal Costanza wrote:
>
> On 7 Apr 2006, at 20:13, eaddy at cs.columbia.edu wrote:
>
>    What makes logging and tracing so different that you think they have
> to be implemented using different mechanisms?
>
>  That's precisely my point.  They are only different insofar as
> AspectJ-like languages requires us to treat them differently.  Any
> other
> perspective on the system (e.g., requirements, design, base
> programmer)
> probably treats them the same.  To implement tracing in AspectJ-like
> languages you just use a call pointcut.  However, to implement
> logging the
> approaches are a) modularize logging completely with fragile and
> complicated aspects (100% AOP), b) use dummy methods and robust
> aspects
> (part OOP and part AOP), and c) use a separate logging API (100% OOP).
>
> Now we have added a fourth option d) use statement annotations and
> robust
> aspects (100% AOP).
>
>  OK, got it. You make the assumption that you only want to log a
> certain irregular subset of join points, while you want to trace a
> very regular complete set of join points. That wasn't clear to me. To
> me tracing can also be about irregular sets of methods.
>
> Don't you reintroduce code tangling with your approach?
>
>
> Pascal
>
>   My earlier reply was an approach to avoiding tangling of a particular
> aspect, but to enable "interested" aspects to get at the join points they
> need without detailed knowledge of the code. By using a generic annotation (
> i.e., "@HeresAnInterestingEvent" ;) that could be applicable to many
> concerns, the pointcuts only need to look for the annotation, not particular
> class and method names, etc. It's based on the idea that any nontrivial
> component should be aware that it will be part of a larger application ("no
> component is an island") and therefore its design should expose appropriate
> information, like state transitions; of course, this statement is something
> we've known for decades! It has just taken on new twists with AOSD.
>
> It's true that you've introduced stuff into the code, but I think the
> evidence is emerging that, properly done, this is the best long-term design
> strategy for components, aspect- and object-based.
>
> Annotations can only go so far, of course. The more complete approach is
> to use an AOSD concept of interfaces, which people like Sullivan, Griswold,
> Kiczales, Mizini, etc., etc. have been working on recently.
>
> Hope this makes sense.
>
> dean
>
> --
> Dean Wampler, Ph.D.
> dean at aspectprogramming.com
> http://www.aspectprogramming.com
> http://www.contract4j.org
> I want my tombstone to say:
>    Unknown Application Error in Dean Wampler.exe.
>    Application Terminated.
>    [Okay]    [Cancel]
>
>
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net
>
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>
>


--
Kevin Sullivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20060408/21b164e7/attachment.htm