Re: can you have interception w/o aop?

Argh, typo, fixed below:

On 4/6/06, Kevin Sullivan <[email protected]> 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 <[email protected]> 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: [email protected], http://p-cos.net
> > Vrije Universiteit Brussel, Programming Technology Lab
> > Pleinlaan 2, B-1050 Brussel, Belgium
> >
> >
> >
> >
> >
> > __________________________________________________
> > AOSD Discuss mailing list    -    [email protected]
> > To unsubscribe go to http://aosd.net
> >
> > Check out the AOSD.net Wiki: http://aosd.net/wiki
> >
>
>
>
> --
> Kevin Sullivan
>



--
Kevin Sullivan

__________________________________________________
AOSD Discuss mailing list    -    [email protected]
To unsubscribe go to http://aosd.net

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