[aosd-discuss] Scope of AOP..

Sahil Thaker sahilt at mail.utexas.edu
Thu Apr 6 11:48:42 EST 2006




> 1. An annotation is purely metadata.  If the program is not woven, or 
> the aspects are disabled, the annotations are simply ignored.  In 
> contrast, a function call is always executed and incurs overhead 
> (unless it is optimized away).
> 
> 2. If a function call requires join point context parameters they must

> be passed explicitly, whereas advice can access jp context implicitly.

> E.g., the logging advice can obtain the file name, line number, and jp

> signature implicitly.  The statement annotation only need to contain 
> the user- defined data.
> 
> 3. A weaver may invoke the advice in a way other than a simple 
> function call.  An event, thread, or even a custom byte code 
> instruction could be used to invoke the advice asynchronously.  A 
> function call is always invoked synchronously.

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'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? How is it different to modularize logging
using your AOP approach than doing the same with OO modularization?
 


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









More information about the discuss mailing list