[aosd-discuss] "AOP considered harmful"

[Mira Mezini]

Eric wrote:

> 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.

First off: We are discussing and NOBODY is insinuating that with AOP - as it
is formulated today - we are already in heaven and shouldn't further
question. We should indeed: That's what researchers are there for. But, when
we do so, it is extremely important to pose the right questions in the right
way that bring us further in the most effective way. 

So, I am trying to say: Yes, question and try to make it better, but in
order to do so effectively, be careful not to start with false assumptions -
or as Gregor says don't start by comparing apples and oranges - because this
might lock you to paths that head to dead ends. 

In this sense, I am merely questioning whether the "AOP considered harmful"
paper or the "AOP strongly depends on tools"-concern expressed by Max are
posing the right questions in the right way. In the following, I will try
again to make my point about what I consider to be false assumptions.

> From: Eric Tanter <etanter at emn.fr>
> Subject: Re: [aosd-discuss] "AOP considered harmful"
> To: "Mira Mezini" <mezini at informatik.tu-darmstadt.de>
>
> But what Max said -which I believe is true- is that without tool
> support, you cannot determine what is going to happen at execution just
> by looking at your code unless you're good enough to 'expand'
> predicates in your mind at any time. Type polymorphism in OOP is
> arguably much easier to grasp in one's head that pointcut shadows.
> So yes, good tools support is even more necessary for AOP I guess. And
> still, another point that is made in the paper is that even with tool
> support, if your pointcuts have dynamic parts, you can only know what
> aspects 'potentially' apply.

First to the point of "being good enough to expand the predicates in your
mind at any time". Why would you want to expand, at all? The point is that
the predicates are first-class abstractions / means of referencing, words in
your language. Did you ever want to expand a while-loop down to the jump
structure needed to implement looping? I doubt... to use Gregor's wording
from one of his talks you probably "say *while* when you mean it!". Or, do
you try to expand down to the method dispatch and interpretation of
statements in the method body in the context of the receiver object any time
you see a method call? 

The point I am trying to make is, once you build abstractions, you look at
them as being elementary units for the next level of complexity. It goes
along the lines of Ron's argument "that the best tool for understanding a
system as a whole is a good design". But, this is not my main point, so I
will not elaborate any longer on this. 

The main point is about the second part in your argument above: 

> Type polymorphism in OOP is
> arguably much easier to grasp in one's head that pointcut shadows.
> So yes, good tools support is even more necessary for AOP I guess. And
> still, another point that is made in the paper is that even with tool
> support, if your pointcuts have dynamic parts, you can only know what
> aspects 'potentially' apply. 

I do strongly question this, because it is somehow implying that AOP is
making things more complex. My point is: Things are complex to start with -
the complexity is inherent in the programs we write. All we try to do is to
structure complexity - we can't remove it. 

Please note that your statement: "Type polymorphism in OOP is arguably much
easier to grasp in one's head that pointcut shadows" is actually an
excellent example of "comparing apples with oranges". I am not going to
debate about how easy or not it is to grasp type polymorphism, although I do
believe that it is not as easy as you postulate [to understand what's going
on at a polymorphic call site, you will probably have to do quite some
non-trivial expansion on the call graph]. The point I would rather want to
make is that in an OO setting type polymorphism alone wouldn't be enough to
express things that you would probably express with pointcut-advice. 

Otherwise, why are those call-back mechanisms such as observers out there?
The latter make our OO programs pretty complex to understand - for a good
discussion on that see Szyperski's book "Component Software". You might say
"let us get rid of them" as you say "let's get rid of around" or let's "only
consider aspects that _add_ some behaviour". That's not actually what
Szyperski says - at least what I interpret him saying is, "we can't do so,
because there are there for good reasons and we actually do need them, so
let's try to find better ways to express contracts in their presence". My
intuition is that AOP can actually help with expressing some of those
contracts - but, this is off-topic and I have to do the exercise first,
anyway.

Sure, you can at any time go back to having less means of expression, but I
challenge you that you will either also restrict the set of systems you
build or that, if you don't do so, you will probably have to simulate the
same effects by other less declarative means of expressions, which
eventually also will end up with more (accidental?) complexity. I might be
wrong, but before making any claims, it is good that any of us do the
exercise of expressing the SAME things with and without AO and than make
claims which would be backed by the comparison. In a paper that is coming up
at ICSE 05 about AOP and modular reasoning, Gregor and I try a very simple
exercise of this kind which shows that AO has the potential to increase
rather than decrease our ability to reason about programs as compared to OO.

Please note the use of the world "potential" here.

My plea to first exercise before postulating claims applies even more to
pointcuts that have dynamic parts. I challenge you to take an aspect that
uses cflow and try to implement exactly the SAME functionality with type
polymorphism only. The resulting implementation will very probably "talk"
about a lot of irrelevant details of the control flow of the program you are
extending with the new functionality, hence, (a) making the new
functionality strongly coupled to implementation details of the existing one
and (b) increasing the accidental complexity of your program. You might use
local thread objects to manage knowledge about the control flow to reduce
some part of the coupling - but aren't you than writing yourself what the
AspectJ compiler or the ajdt tool would otherwise write for you? The cflow
on the other hand gives you a means to abstract over control flows talking
only about points in the control flow that are relevant and hiding the rest.

[Klaus Ostermann and myself have done a simple exercise of this kind in a
FSE 04 paper on variability management with aspects and feature-oriented
programming, in case you are interested to better understand my point.]  

So, in summary, what I am trying to point out is: Tool support and all that,
be it in OO or AO is needed because of the inherent complexity out there. AO
is going one step further in giving you some abstraction mechanisms that
make tool support easier because they make existing implicit structures
explicit and by doing so reduce some accidental complexity - for a good
discussion also see the paper by Lopes et al on "naturalistic referencing"
at OOPSLA 03 Onward. 

Agreed, they - the abstractions and tool support we have right now - might
not go as far as one might wish them to, so start from there and make it
better. My concern is that bold provocative claims not backed by careful
exercising of the kind "AOP considered harmful" might keep some smart minds
away from posing the right and important questions which may make a change
for the better.