RE: [aspectj-users] Philosophical Questions

[Ramnivas Laddad <ramnivas@xxxxxxxxx>]

A few thoughts:

1. The debugging support is probably the most important differentiator 
   in favor of AspectJ. When some crosscutting logic is executed 
   I not only want to know the code getting executed but also *why*
   did I reached that code. Embedding together pointcuts and advice 
   that make up the crosscutting logic in a module as implemented 
   in AspectJ makes this a simple and easy to explain. 
   You can't do the same thing with weaving rules expressed in 
   a separate XML document.

2. The claimed simplicity of the new AOP frameworks, I believe, is 
   at least partially attributed to the omission of many crosscutting 
   constructs. Although I don't find AspectJ to be difficult, having 
   used AspectJ for a long time, I am clearly not an unbiased judge. 

   Watching the evolution of some of these frameworks, it seems 
   that each one is eventually adding many of the AspectJ features 
   over time. For example, by omitting control-flow based pointcuts, 
   you can create a simple AOP language. Such a language can then 
   claim to be "simple". However, as soon as you start creating
   nontrivial applications that go beyond logging and tracing, 
   you realize that the lack of control-flow pointcuts, while 
   keeping the language simple, makes the aspects hard to write.

3. The new frameworks will help for AOP as long as they provide 
   good examples of how crosscutting concerns can be implemented in 
   those frameworks. These examples, irrespective of language 
   (or framework), will guide the community in understanding set 
   of definitive characteristics of AOP implementations backed 
   by practical validity. Perhaps then we can more subjectively
   differentiate interceptor-based approaches from "true" AOP.

-Ramnivas

--- Gregor Kiczales <gregor@xxxxxxxxx> wrote:
> I'm really glad you sent this message.  This reply is about a general
> point, I'll tackle the specific points later today.
>  
> The flurry of alternative AOP frameworks is clearly a good thing. It
> shows that AOP has moved from the invention phase to the first
> innovation phase. More people are looking at the technology, in a
> solution oriented approach, to see what it can do for them.This
> will be an exciting time.
>  
> But while I think lots of innovation is great, I worry that these
> systems may cause people who are just starting to learn about AOP
> to reach some false conclusions.  Specifically:
>  
>  - because these systems have no IDE support, they run the risk of
> stoking the false argument that AO programs are hard to
> understand or debug. With AspectJ, a simple ajdt demo is enough to
> show that these problems are solved.
>  
>  - because these systems are dynamically typed, they run the risk of
> convincing people that AOP is inefficient and also that
> debugging will be more difficult with AOP.
>  
>  - because these systems don't necessarily have orthogonal join point
> models, they may seem simpler, but run the risk of making
> larger AOP programs more complex to write and/or understand.
>  
>  - because most of these systems are a subset of AOP, they run the
> risk of causing people outside the community to complain that
> "the AOP people are talking a lot about a very little". For example,
> many people look at these systems and conclude that AOP is just
> interception -- they miss the whole point about how pointcuts allow
> building up crosscutting structure.
>  
>  - because of the claims people make about these systems, they run
> the risk of causing people to believe that no one is doing any
> commercial AOP yet, and that AspectJ doesn't work. Many AOP
> developers would be better served, IMHO, to use AspectJ with its much
> higher degree of engineering, documentation and support.
>  
> Don't get me wrong, I strongly believe this round of innovation
> should continue, it is a great thing. I am personally enjoying
> discussions with some of the authors of these new systems as to
> elements of their design.
>  
> But I wish the voice of AspectJ experience was more represented in
> this round of debate about using AOP in practice.  For example
> this idea that AspectJ is too powerful needs some debunking. Its
> trivial to subset AspectJ and still end up with an orthogonal,
> type-safe, efficient, system that has 5 years of user experience with
> it. If size is the issue, that is probably a better way to go.
>  
> So...
>  
> I'd really like to encourage AspectJ users who have running code and
> experience to speak up more on the many blogs that are hosting
> most of this round of AOP discussion. Please speak up! (Its sort of
> frustrating that all this happens in individual blogs rather
> than discuss@xxxxxxxx, but that's a whole other issue!)
> 
> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx
> [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Merrick
> Schincariol
> Sent: Saturday, July 05, 2003 8:03 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: [aspectj-users] Philosophical Questions
> 
> 
> 
> Having just got back from TheServerSide Symposium in Boston, I can
> report that AOP was definitely the talk of the conference. What
> was surprising to me, however, was the lack of focus on AspectJ. Most
> comments were of the form "it's too powerful for most
> developers" or that the special compiler makes it difficult to sell
> in most organizations. Instead, most of the talks focused on
> newer "pure Java" AOP frameworks.
> 
> I personally find AspectJ to be a well designed implementation of AOP
> concepts. On my weblog (
> <http://www.freeroller.net/page/mschinc>
> http://www.freeroller.net/page/mschinc), I've been documenting my own
> exploration of the
> capabilities that AspectJ provides. Looking closer at "pure Java"
> approaches like AspectWerkz ( <http://aspectwerkz.codehaus.org/>
> http://aspectwerkz.codehaus.org/) something has been bothering me,
> but I haven't been able to put my finger on it. I'd like to put a
> couple of questions out to the list and see where your thoughts are
> on the subject.
> 
> 1) Can Aspects themselves be broken down into smaller sub-components?
> 
> 
> Most of the Java AOP frameworks break out aspects into a number of
> different pieces. For example, you implement your advice as one
> Java class, your introductions as another and then define (usually
> using XML) the pointcuts and the relationships between the
> components. So one Aspect could actually require many files to
> implement and define. Does the complexity of this approach interfere
> with the AOP philosophy? My fear is that when the implementation
> requirements are complex, from a language point of view, you start
> to lose track of the problem you are actually trying to solve.
> 
> As an aside, I think the AspectWerkz design for advice is broken.
> Because each type of advice is a class (pre, post and around) and
> each advice class extends a pre-existing class, you can't share any
> information between different types of advice on the same
> pointcut.
> 
> 2) Can pointcuts be modeled separately from advice? 
> 
> This follows on the above point, but it's one that I find a little
> odd. Most (all?) of the pure Java approaches define their
> pointcuts in one file and their advice in another. Presumably this
> means that advice can be reused across multiple different aspect
> definitions. From a philosophical point of view, can advice be
> modeled truly independently from pointcuts? I would think that
> certain types of advice, particularly when dealing with cflow and
> other advanced join points, really require the pointcut definition
> to be present in order to make sense.
> 
> 3) What role, if any, should metadata play in AOP? 
> 
> I know Gregor has commented on the use of metadata a couple of times,
> but the JBoss group is charging ahead with their "AOP" product
> which encourages developers to use class metadata to load library
> aspects. This strikes me as wrong in many ways, but the message
> that is reaching the development community is that interceptors and
> metadata are all you need to do AOP. Is this just a function of
> what's easy to implement, or are people really having trouble
> grasping the concepts?
> 
> I'm looking forward to hearing your thoughts. 
> 
> Cheers, 
> 
> Merrick 
> 
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com