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