[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