[aosd-discuss] "AOP considered harmful"

[Ron Bodkin]

Thanks Eric. I agree that providing more effective means of specifying and
verifying contracts and formalizing interfaces for aspects would be useful.
I don't view the current state of AOP as *problematic*. Then again, I will
admit that I like things like multiple inheritance (I also think you can
strike a balance by making simple rules that exclude things like complex
resolution of conflicts and virtual bases...)

I also think that around advice really has its place, even though I grant
that its power is best reserved for situations where it's really required
(such as caching), ... Of course, even with before advice you can always use
things like exceptions to change the control flow of a program.

This work seems like interesting research that can improve something that's
already working well. It's a shame when an analyst with apparent ulterior
motives is able to seize on position papers that make broad claims and then
use them to allow performing a hatchet job...

-----Original Message-----
From: Eric Tanter [mailto:etanter at emn.fr] 
Sent: Monday, April 25, 2005 11:40 AM
To: Ron Bodkin
Cc: <discuss at aosd.net>
Subject: Re: [aosd-discuss] "AOP considered harmful"

Thank you Ron, very interesting reply.

I completely agree that the best thing among all is a good design and 
that AOP allows for cleaner designs. And that to understand any complex 
application, you also need good tools.  I also agree that the 
"special-case obscure artefacts" are no solutions neither.

But still, this mailing list is _discuss_ at aosd.net (notice the 
emphasize on 'discuss'), and it seems to me a bit exagerated to 
insinuate that AOP -as it is formulated today- has no problem, and that 
we shouldn't questions ourselves.

Powerful stuff like multiple inheritance has been withdrawn from some 
major mainstream languages because its complexity and excessive power 
was too much compared to its benefits. It may be good to think about 
ways for this not to happen with AOP.

The work of Aldrich on specifying contracts for aspects is a good 
example in this direction. It's less powerful that "plain AOP" because 
you need to anticipate the 'aspect contract', but that brings much more 
confidence in what happens when applying aspects. Also, in their EAOP 
proposal, Douence, Sudholt et al. only consider aspects that _add_ some 
behavior. They exclude 'around' because "then you cannot say anything 
about what will happen". And I imagine there are other proposals around 
that target a  more restricted AOP.
I'm not saying these proposals are the definitive and good solution to 
the problems they identify, just that these problems do exist, and are 
worth discussing (and so, especially on this list ;)).

-- Eric