Re: Scope of AOP..

Dean Wampler <[email protected]>
Newsgroups gmane.comp.programming.aspect.general
Organization Aspect Research Associates
Message-ID <[email protected]>
Pascal Costanza wrote:

On 7 Apr 2006, at 20:13, [email protected] 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    -    [email protected]
To unsubscribe go to http://aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.