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

Thu Apr 6 22:34:00 EST 2006

Time to interject that...    this discussion is quite focused on an AspectJ
model of AOP.

One of the main AspectJ design goals was to be the simplest and most
conservative generic AOP system we could design. Its not all of AOP, nor was
it ever intended to be. So while anything like a definition of AOP should
clearly include AspectJ, it needs to include a lot of other things as well.

As one example, consider the RG system described in [1] and [2]. I think its
a very interesting example, because its a case where the abstract functional
composition and the actual composition of implementation are radically
different. This kind of crosscutting composition is more clear in the RG
case than in the AspectJ case, although it also happens there.

I guess all I'm trying to say is that we should be careful when we see
something like:

- The technical characterization: An approach supports AOP when it
provides a join point model, a pointcut language and advices. 

This is a useful characterization, in that it captures the region of the AOP
design space that is most popular today (AspectJ, Spring...).  But not all
of the AOP like mechanisms in AspectJ (only covers dynamic join points,
pointcuts and advice, the static join point model, aka inter-type
declarations). Its also much more narrow than what the term AOSD means
today, and what AOP originally meant. 

Of course both both of these papers are old, and starting to show their age
in various ways.
But the point about RG being in the AOP design space remains valid IMHO.
[1]
http://www2.parc.com/csl/groups/sda/publications/papers/PARC-AOP-RG97/for-we
b.pdf
<http://www2.parc.com/csl/groups/sda/publications/papers/PARC-AOP-RG97/for-w
eb.pdf> 
[2] http://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf

  _____  

From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On Behalf
Of Kevin Sullivan
Sent: Thursday, April 06, 2006 7:16 AM
To: Pascal Costanza
Cc: Roger Johansson; discuss at aosd.net
Subject: Re: [aosd-discuss] can you have interception w/o aop?

Argh, typo, fixed below:

On 4/6/06, Kevin Sullivan <sullivan.kevinj at gmail.com> wrote: 

I see AOP as currently discussed addressing *two* general goals.

1. better accommodate the fact that concerns are crosscutting, in general,
and hierarchical decomposition is therefore inadequate 
2. better accommodate the fact that modularization can complicate evolution
in the face of unanticipated changes in specification 

I believe there are benefits in thinking about and in addressing these
issues separately (separation of concerns). In particular, we've shown that
it's possible to use AOP mechanisms to address #1 without necessarily buying
into some of the more controversial policies by which AOP typically
addresses #2: namely policies that demand non-enforceability of
abstractions. The idea here is that a range of program and execution details
must unrestrictably remain open to subsequent advising by aspect modules, on
the assumption that because one can't anticipate what downstream clients
will need, one is best served by leaving open a broad and detail-rich
interface for them to exploit. The XPI notion we've discussed here recently,
for example, reconciles traditional notions of information hiding modularity
and integral, explicit, abstract interfaces with the need to represent
crosscutting behaviors, but it does this without committing to the
hypothesis that evolution is best accommodated by radical openness. In other
words, it addresses #1 without taking a stance on #2. I tend to think we're
on much more solid ground today with respect to #1 ("modularization of
crosscutting concerns") than with #2 (a form of "obliviousness"). On #2, 

Here I meant #1 -- modularization of crosscutting concerns (as opposed to
obliviousness) 

we will find, I believe, that AOP contributes both to our understanding of
the need to consider forms of modularity in design that transcend the forms
that you get by practicing OOD/OOP in traditional/straightforward ways, and
to our toolkit of mechanisms for achiving better forms of modularity. Of
course there are other and earlier mechanisms and approaches addressing
related problems. Eventually I think we'll end up with a coherent set of
mechanisms and a better software engineering understanding of how to achieve
more appropriate modularity in software design, perhaps leading to what will
look like an enhanced form of OOP/OOD with a more balanced emphasis on
"objects," on the one hand, and "crosscutting behaviors," on the other. My
sense is thus that we're now well on the way to having a good handle on #1.
As far as #2, I think it remains a very interesting area for research. I
personally do not believe that it's realistic to open up details of all of
the modules of complex systems to downstream advising without the
stabilizing influence of intervening design rules / interfaces. A good
example: If a very large operating system vendor were to allow
indiscriminate advising of its library code (whether in source or object
form) then it would never again be able to release new library
implementations without breaking the applications of thousands, perhaps
millions, of application developers. That's just not a model that seems
realistic. On the other hand, there is simply no question that
modularization  incurs opportunity costs. Nor do I believe we yet have a
theory of modularity in design adequate to help designers understand when
and how to modularize for greatest ( e.g., business) advantage. So, although
I'm somewhat pessimistic about policies of radical openness, I do think that
the larger question of when and how to modularize, based on the ability to
model the costs and benefits 

of  

modularity, remains an important area for research. Notions of open
implementations, obliviousness in AOP, and so forth do call into question
somewhat settled but still arguably inadequate notions of modularity, and so
can help to spur such research. In that way, at a minimum, I think, they
make a valuable contribution to the research enterprise. We've just got a
longer way to go on #2 than on #1 for a profitable transition to practice. 

Kevin

On 4/6/06, Pascal Costanza < pc at p-cos.net <mailto:pc at p-cos.net> > wrote: 

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/
<http://www.cs.ubc.ca/%7Egregor/papers/> 
masuhara-ECOOP2003.pdf

Pascal

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

__________________________________________________ 
AOSD Discuss mailing list    -    discuss at aosd.net
To unsubscribe go to http://aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki

-- 

Kevin Sullivan 

-- 
Kevin Sullivan 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20060406/8873ae31/attachment-0001.htm