[aosd-discuss] AW: discuss Digest, Vol 19, Issue 9

[Gregor Kiczales]

I agree that modularity is the fundamental issue, but I see it
somewhat differently.

As I see it, what's underlying AOP is the claim that the old definitions
of modularity and modular reasoning (MMR) were wrong. They were well
worked out, and highly technical. But they failed to do justice to (at
least) one problem that arises in real systems, the problem of modular
implementation of crosscutting concerns (CCC).

That's a radical statement, and one that AOP proponents often pull
their punches on. 

But "AOP and Modular Reasoning" [1] shows that:

  - in the presence of CCC, code written "the old way" satisfies
    the old technical definition of MMR, but fails to satisfy a
    simple first-principles definition of modularity for the CCC.

  - an AOP implementation of the CCC, does satisfy the first
    principles definition of MMR, but fails to meet the old
    technical definition of MMR.

What this is saying is that the old technical definitions of
"modularity" and "modular reasoning" were not in fact as general
as they could be. They just named a particular notion of modularity. 

In such a situation, we could say "OK, let's invent new terms to
talk about the more general kind of modularity and modular reasoning,
and the old-style definitions and AOP can both be special cases".

But "modularity" and "modular reasoning" are too good as terms to
just name a special case. They should name the more general notion
of modularity, which AOP points out has to be something more than
the old technical definitions.

So what remains to be done (or at least one thing that remains to
be done) is to figure out this more general notion of modularity,
that encompasses AOP and more traditional SOC mechanisms.  By
the time we get that figured out, we'll probably have some new
mechanism that breaks that (in a good way) to contend with.


[1] AOP and Modular Reasoning. Kiczales and Mezini. ICSE 05.
    http://www.cs.ubc.ca/~gregor/papers/kiczales-icse05-aopmr.pdf





> -----Original Message-----
> From: discuss-bounces at aosd.net 
> [mailto:discuss-bounces at aosd.net] On Behalf Of Jonathan Aldrich
> Sent: Monday, April 25, 2005 1:04 PM
> To: discuss at aosd.net
> Subject: Re: [aosd-discuss] AW: discuss Digest, Vol 19, Issue 9
> 
> Mira wrote (and Gregor supported):
> > I disagree with the above. AOP makes great tool support like ajdt 
> > *possible*
> > rather than "strongly depending on them"! Pointcuts make 
> the crosscutting
> > structure, which implicitly exists anyway in an OO 
> equivalent, explicit 
> > and
> > hence displayable by a "stupid" tool. By this, it actually improves 
> > overall
> > program understanding rather than reducing it, IMHO.
> 
> I think there's some truth to both sides here.  AOP *does* 
> make it easier to 
> understand and evolve a concern that *crosscuts* an ordinary OO 
> decomposition--and it does so even without tool support.
> 
> However, without tool support, AOP makes it harder to 
> understand and evolve 
> *base* code, for the reason that everyone cites: you can't 
> see which aspects 
> apply to it, and so you can't tell what's going on, and if 
> you edit the code 
> you might break the aspects.  If you claim, as Gregor did, 
> that AOP *only* 
> helps you, even without tools, that's because you're ignoring 
> the base code.
> 
> Tool support mitigates this issue, at least in a world where 
> you know all 
> the pointcuts that are going to apply to your code--because 
> now you can see 
> which aspects apply to code and make sure that you don't 
> break them as you 
> evolve the system.  So without tool support, AOP makes it 
> easier to deal 
> with crosscutting code but harder to deal with base code.  With tool 
> support, AOP makes it easier to deal with crosscutting code 
> and about the 
> same (maybe better, maybe worse) for base code.  In this 
> sense, AOP strongly 
> depends on good tool support.
> 
> If you don't have tool support, AOP can still be a good idea; 
> but that's a 
> judgment call which will depend on the situation.  If the 
> improvement in 
> modularity for crosscutting code is "greater" than the loss 
> of modularity 
> for base code, that would be an argument in favor of aspects.
> 
> As Eric Tanter mentioned, I have been working on the theory 
> of a module 
> system that can be used to provide a slightly different tradeoff in a 
> distributed development setting where you don't know all the 
> aspects that 
> apply to your code.  In this solution, you add explicit 
> pointcuts to the 
> interface of a module and aspects can only advise those 
> explicit pointcuts, 
> or public members of the module.  The tradeoff here is that 
> your reasoning 
> about base code within a module is basically unaffected, but 
> as the solution 
> is not completely oblivious and as you are restricting 
> aspects, you gain 
> only part of the benefit of aspects.
> 
> There's no free lunch: either you restrict the aspects with a 
> module system, 
> you use tools to show where aspects apply (which may be 
> impossible in the 
> distributed development case), or you lose some modular 
> reasoning about base 
> code (but still gain modular reasoning about crosscutting 
> concerns, as 
> Gregor says).
> 
> 
> Aspects vs. Friends
> ----------------------
> The "breaking encapsulation problem" (which is primarily a 
> problem without 
> tool support, or in distributed settings where tool support 
> is impossible) 
> is different from the "friend" issue that Awais cites in C++. 
>  In C++, you 
> can look at a class and see who its friends are, so you know who is 
> depending on your code.  With aspects, you don't know who is 
> advising you 
> unless you have tool support, so these dependencies are not 
> explicit and are 
> therefore more dangerous.
> 
> The issue is *not* whether AOP is misused or not.  It is that 
> even good uses 
> of AOP can be confusing if someone looking at the base code 
> without tool 
> support can't easily see which aspects apply.
> 
> 
> On tools in AOP and OOP
> -----------------------------
> Some of the analogies drawn between AOP and OOP are overly simplistic.
> 
> There is a difference between pointcuts in AOP and 
> polymorphic call sites in 
> OOP.  In OOP, the call site is explicit, and you can go to 
> the interface of 
> the statically bound class and get the specification of what 
> the method is 
> supposed to do.  It's true that you need tool support to try 
> to figure out 
> which method is *actually* invoked, but most of the time you 
> don't care: 
> just reading the specification in the interface or superclass 
> tells you 
> enough of what you need to know (hopefully your library 
> author did include a 
> specification, at least in javadoc!).  In AOP, the advice is 
> only explicit 
> if you have tool support, which is why I would argue that 
> tool support is 
> more important for AOP than for OOP.
> 
> Just my 2 cents ;-)
> 
> Jonathan Aldrich
> http://www.cs.cmu.edu/~aldrich/
> 
> 
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net
>