[aosd-discuss] can you have interception w/o aop?
Pascal Costanza
pc at p-cos.net
Fri Apr 7 12:36:09 EST 2006
On 7 Apr 2006, at 05:34, Gregor Kiczales wrote:
> 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.
OK, sorry. What I had in mind was the characterization you gave in
your ECOOP 2003 paper, that is (in similar words as above, not
verbatim from your paper): An approach supports AOP when it provides
a join point model, means of identifying join points and means of
effecting semantics at identified join points.
Pointcuts are the means of identifying join points, and advices are
the means of effecting semantics at pointcuts in AspectJ-style
approaches. Indeed, the difference is subtle, but important.
Pascal
> 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-web.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> 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
>
>
>
> --
> Kevin Sullivan
--
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20060407/02f32483/attachment.htm
More information about the discuss
mailing list