[aosd-discuss] can you have interception w/o aop?

Roger Johansson roger.johansson at compona.com
Thu Apr 6 07:52:39 EST 2006


>> It seems to me that two characterizations are currently typically  ..

Ok, now we're talking.

but is those two things really addressing the same thing?

isnt the goal based addressing the "essence" of AOP, while the technical 
addresses the requirements for an _AOP Framework/Engine/Language_  ??

surely I must be able to make a mini use-case specific AOP engine/compiler 
that pointcuts via some static code instead of a DSL , just because I might 
know that thats all I need in this specific usecase.
and it would still be AOP , wouldnt it?

so AOP as a concept can exist w/o DSL pointcut languages etc, while a 
competent AOP Framework/Language cannot

or?

//Roger





----- Original Message ----- 
From: "Pascal Costanza" <pc at p-cos.net>
To: "Roger Johansson" <roger.johansson at compona.com>
Cc: <discuss at aosd.net>
Sent: Thursday, April 06, 2006 2:21 PM
Subject: Re: [aosd-discuss] can you have interception w/o aop?


>
> On 6 Apr 2006, at 11:27, Roger Johansson wrote:
>
>> Hi, thanks for the sample.
>> what would it take in order to make that sample AOP?
>>
>> Im just trying to find a clear definition on when something is AOP  and 
>> when its not.
>
> It seems to me that two characterizations are currently typically  used. 
> One describes the goal, and the other describes what seems to  be common 
> to all approaches considered AOP.
>
> - The goal-oriented characterization: Aspects are modularizations of 
> crosscutting concerns.
>
> - The technical characterization: An approach supports AOP when it 
> provides a join point model, a pointcut language and advices.
>
> In my perspective, the goal-oriented characterization is too weak.  There 
> are approaches to modularize crosscutting concerns that are  typically not 
> considered to be AOP, like metaobject protocols or code  transformation 
> frameworks. So at least, the goal-oriented  characterization alone is not 
> enough.
>
> My impression is that the technical characterization indeed captures  what 
> most people think of when they talk about AOP. At least, when I  talk to 
> people from the AOP community, they tend to discuss issues  wrt pointcut 
> languages sooner or later. Since a join point model  without a pointcut 
> language doesn't make a lot of sense, and since  advice were already 
> around before the advent, I think this boils down  to the notion that you 
> have AOP when you have a (dedicated) pointcut  language.
>
>> you have " (let ((fib (lambda (x)" which i guess is similair to a 
>> pointcut of the function "fib" ?
>
> The (lambda (x) ...) part creates a (nameless) function. The (let  ((fib 
> ...)) ...) part binds that function to the variable fib.
>
> It's not really a pointcut, since the new binding for the local fib  is by 
> default unrelated to the global fib binding. In other words,  these are 
> name that just "happen" to be the same. The connection  between those two 
> definitions of fib is only there because the local  fib eventually calls 
> the global fib in its definition.
>
>> you have the redefined body of the function which i guess is  similair to 
>> the advice / interceptor
>
> Yes, it's similar, but not the same. There is no pointcut and/or  advice 
> involved here. It's "just" a very simplified example for  intercession.
>
>> what fundamental parts are that sample missing in order to be aop?
>
> It's hard to demonstrate "AOPishness" on such a simple example  because 
> there's only one function that is wrapped by another one that  provides a 
> kind of before advice. In the general case, pointcuts  crosscut the 
> program structure, so they pick out several (more than  one) join points. 
> So in order to turn this example into something  "AOPish", you need more 
> functions and a way to pick out a meaningful  subset of those functions.
>
> It's probably a good idea to read http://www.cs.ubc.ca/~gregor/papers/ 
> masuhara-ECOOP2003.pdf
>
>
> 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
>
>
>
> 




More information about the discuss mailing list