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