[aosd-discuss] "AOP considered harmful"

[Jari-Pekka Arvo]

Hi,

I'm writing my Master's Thesis about modularity in AOP and finally this 
list is getting interesting :-)

I couldn't agree more with this latest post. If AOP is to be a popular 
AND robust programming
technique then it's advocates should be keen to address it's obvious 
shortcomings and discuss
how to avoid misuse of it's very powerful features. I think that recent
articles (f.ex. Kiczales, Aspect-Oriented Programming and Modular 
Reasoning, 2005) are moving
towards that.

However, much too often in these discussions occurs some how lame 
(forgive me) arguments like
"C++ has friends that breaks encapsulation too" or "you can make bad 
code with any language"
or especially "any real critique of AOP needs to address the 
shortcomings that motivated such alternatives".
I don't think so.

Critique is not blaming or insulting, it's reasoning. If most AOP 
implementations has mechanisms to break
encapsulation, then they do so. That feature does not go away by 
changing the subject. More interesting
discussion should be when and how to apply these mechanisms. In other 
words when it is justified and
reasonable to break traditional concept of modularity. After all 
crosscutting concerns are handled in OO
and not necessarily in less elegant way.

-JP-

Eric Tanter wrote:

> 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
>
>
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net