[aosd-discuss] Scope of AOP..

Marc Eaddy eaddy at cs.columbia.edu
Thu Apr 6 16:15:39 EST 2006

Hi Shahil,

	Good comments.  My responses are below: 

> As Pascal has suggested there are trivial workarounds to 
> these using existing approaches, including point 3 - function 
> call would be synchronous but you would have a logging module 
> that executes the actions asynchronously and returns from the 
> call without wait. And one could use design patterns, flags, 
> or simple metaprogramming approaches to select/deselect 
> functionality, just as cleanly as you select/deselect aspects 
> at weave time. 

I want a unified AOP solution rather than have some crosscutting concerns
implemented using OOP and some modularized using AOP.

> I'm not saying it is not a good idea to have these forms of 
> annotations, but if these can be equated to explicit function 
> calls, are you still using AOP to modularize it?

I see these "annotation calls" as the base code residue needed by the AOP
implemention of the crosscutting concern.

> How is it 
> different to modularize logging using your AOP approach than 
> doing the same with OO modularization?

I'd like to modularize crosscutting concerns in a uniform way, e.g., using a
unified AOP approach.  Also, some AOP languages (AspectJ) provide extra
niceties like jp context exposure, aspect instantiation, and flexible and
optimized advice invocation, which the base language doesn't provide.

> > Attempts at completely modularizing the logging concern 
> using standard 
> > AspectJ, for example, have not been very successful:
> > 
> > 1. the resulting pointcuts were very fragile;
> > 
> > 2. the pointcuts were not powerful enough to advise the exact join
> points
> > needed; and
> > 
> > 3. a separate advice is needed for each unique message 
> resulting in a
> lot
> > of
> > redundant code.
> I Agree.
> > In short, what you gain in modularity, you lose in locality and 
> > explicitness.  Using our approach, the aspect only modularizes the 
> > portions of the logging concern that can be modularized 
> /effectively/: 
> > the
> logging
> > policy, what jp context to include in the log message, 
> when/where/how 
> > messages are logged, etc.  The portion of the logging concern that
> cannot
> > be
> > modularized effecitvely, e.g., the user-defined log message and
> location
> > in
> > the source code, are expressed using (local and explicit) statement 
> > annotations.  We believe this is the proper balance for the logging 
> > concern.
> Ok.
> > What you seem to be implying is that the base programmer is aware of
> the
> > aspects in the design but the base code is oblivious, i.e., the base
> code
> > does not need to be "prepared" in order to support the aspects.  How
> is
> > this
> > an improvement?  Since the base programmer is already aware of
> aspects,
> > what's wrong with "using them" explicitly in the base code? 
> I agree; if you must be implicitly designing the joint 
> points, why not make it explicit? Certainly there are times 
> when obliviousness does not serve well.
> My question to the AOP community is this: If we do what you 
> have suggested here - make joint points explicit through 
> annotations, function calls, macros etc, is it still considered AOP?

Very good question!  The goal of AOP is to separate crosscutting concerns.
If the final result of annotations, etc. is that the system is more modular
and decoupled, I think the answer is yes, it is AOP.

More information about the discuss mailing list