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

[Kevin Sullivan]

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, 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 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> 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/
> 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
>
>
>
>
>
> __________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20060406/a558d441/attachment-0001.htm