Re: Fw: invasives aspects

On 1/9/07, Ashley at Metamaxim <[email protected]> wrote:

>
> > The various arguments that AOP does not support modular reasoning
> invariably rest on the notion that we ought to be
> > able to do modular reasoning without even simple machine support -- to
> be able to print code out and reason about it
> > effectively from the printouts. Since no practicing developer tries to
> reason about code today without tool support, even
> > for OO programming, it seems an unrealistic constraint to place on AOP.
>
> The paper I cited does not suggest that reasoning must/should be possible
> without tool support. I can see that using a tool might make reasoning
> easier, but it is difficult to imagine that it can affect whether reasoning
> is theoretically possible.
>

I believe that it does actually.  Consider:

obliviousness threatens conventional modularity
principles and undermines a programmer's ability to reason
locally about the behavior of their code.
...
to understand
the semantics of code in an aspect-oriented language such as AspectJ,
programmers will have to examine all external aspects that
might modify local data structures or control flow.

The idea that you have to manually examine all aspects that might affect the
behavior at a join point comes directly from the idea of not being able to
use tool support to do it. The theme underlying this is that OO, by
comparison, is amenable to modular reasoning because you can follow an
explicit chain of named reference links (calls, instantiations etc.) to see
what is happening. But, if you allow even very simple AOP tool support, then
you recover the exact same sense of being able to follow explicit references
to code that might run at the join point.

> IMHO all of these arguments against 'invasive' advice miss the key point:
> without AOP modularity constructs, true
> > crosscutting concerns cannot be reasoned about in a modular way. With
> AOP constructs they can.
>
> I did not understand this comment. Can you elucidate, please?
>


In the paper that Mira and I wrote (AOP and Modular Reasoning) we show that
the canonical display updating concern, implemented without AOP, requires
whole program searching in order to reason about it. By contrast, AOP
supports modular reasoning for display updating, as long as you allow simple
tool support. This part of the paper -- the demonstration of the failure of
non-AOP to be able to support modular reasoning in some cases, is I believe
critical. Unfortunately it seems we weren't clear  about that.

P.S. Note that the central technical contribution of the Harmless Advice
paper is not at question. Its great stuff in  terms of reasoning about the
interaction between crosscutting concerns at a join point.

Rgds
> Ashley
>

_______________________________________________
discuss mailing list    -    [email protected]

To unsubscribe and change options, go to:
http://aosd.net/mailman/listinfo/discuss_aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki