[aosd-discuss] Scope of AOP..

[Marc Eaddy]

> -----Original Message-----
> From: Sahil Thaker [mailto:sahilt at mail.utexas.edu] 
> Sent: Wednesday, April 05, 2006 11:24 PM
> To: 'Marc Eaddy'; discuss at aosd.net
> Subject: RE: [aosd-discuss] Scope of AOP..
> 
> 
> Hi Marc,
> 
>  > Our solution [1] was to use "statement annotations" to express the
> logging
> > concern:
> > 
> > someMethod() {
> > 	@Log("Some debug statement")
> > 	...blah blah...
> > 	@Log("Another debug statement")
> > 	...blah blah...
> > }
> > 	I think part of the problem is the obliviousness requirement.
> Why
> > not allow the base programmer to not only be aware of 
> aspects, but to
> also
> > use them ubiquitously to implement crosscutting business logic and
> > "functional" requirements?
> 
> How is this different to making a function call?
>  

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.

> 
> > 	I think part of the problem is the obliviousness requirement.  
> 
> It is possible to have heterogeneous cross cuts while being oblivious,
> you will just have many of them, e.g one for each unique log 
> statement.
> An advantage may be that logging module is more cohesive.
>  

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.  

The resulting aspects are pretty much incomprehensible since the log
messages do not make sense in isolation, i.e., they can only be understood
in the context of the source code.

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.

> 
> When I say oblivious I mean oblivious from the point of view of
> code-base, not from design.
>

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? (Unless you are
refering to the rare situtation when the base code can't be modified for
some reason.)

When we bring the full power of AOP to the base programmer, we come closer
to realizing the full potential of AOP to modularize ALL types of
crosscutting concerns, not just the "nonfunctional" ones. :)