[aosd-discuss] Scope of AOP..

[Pascal Costanza]

On 6 Apr 2006, at 09:04, Marc Eaddy wrote:

>> -----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).

I would expect that modern runtime environments indeed optimize such  
function calls away.

In Java, I suspect that the logging method is roughly implemented  
like this:

static boolean loggingEnabled = true;

public void log(String msg) {
   if (loggingEnabled) {
     System.out.println(msg);
   }
}

A compiler can compile this to an empty method when loggingEnabled is  
false, and the JVM can then optimized the call to an empty method  
away. (I would be surprised if JVM implementations didn't do this.)

With macros, you can achieve a similar effect. Here is a similar  
macro in Common Lisp:

(defconstant +logging-enabled+ t) ; t for true

(defmacro log (msg)
   (if +logging-enabled+
     `(print ,msg)
     '()))

A macro returns the code that should be used instead of the macro  
invocation. In this macro, when +logging-enabled+ is false, the macro  
returns an empty list of code, which results in a no-operation.

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

You can as well inspect context information in advanced macro  
systems, for example by inspecting environment objects in (some)  
Common Lisp implementations or syntax objects in (some) macro systems  
for Scheme.

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

That's also trivial to achieve with macros.

> 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. :)

People have been doing this with macro systems for decades.


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium