[aosd-discuss] Scope of AOP..
eaddy at cs.columbia.edu
Thu Apr 6 16:00:18 EST 2006
Great point! Using Gregor's terminology, "Event" is used as an
"annotation property" whereas "Log" is an "annotation call" . In his
design rule for using annotations, he says
"choose a name that describes what is true about the points, rather than
describing what a particular advice will do at those points"
I'll update my examples/paper to use annotation properties instead
of annotation calls where appropriate.
 G. Kiczales and M. Mezini. "Separation of Concerns with Procedures,
Annotations, Advice and Pointcuts," In Proc. of the European Conference on
Object-Oriented Programming (ECOOP'05), Springer LNCS, July 2005.
> -----Original Message-----
> From: Dean Wampler [mailto:deanwampler at gmail.com]
> Sent: Thursday, April 06, 2006 10:55 AM
> To: Marc Eaddy
> Subject: Re: [aosd-discuss] Scope of AOP..
> I agree that embedding annotations is one way to create "aspect-aware"
> components without assuming particular aspects. So, here's
> what I would do differently to support aspect-awareness
> without assuming a particular aspect, in this case logging.
> What the example is really saying is that there are "interesting"
> points of execution that someone might want to know about. In
> this case, it's assumed that logging those events is
> adequate. Maybe another observer would like to watch them in
> real time and take some appropriate action.
> So, I would redo the example with 3 changes.
> (i) Replace @Log with @Event or something generic like that
> (or maybe @Note or @Report ??). Keeping the message strings
> is fine, in case some aspect needs them.
> (ii) Refactor the code so that every point where @Event
> appears is actually at a separate method call, on the general
> design assumption that if a "joinpoint" is interesting enough
> to an observer, it probably should be a separate method call,
> which in practical terms, better supports advising.
> (iii) Write a logging aspect that watches for "@Event's" and
> logs them.
> Now you've got a component that is aware that other
> components are interested in significant events (like state
> changes) and it provides the hooks needed for observers to
> watch for those events. In other words, the component has
> exposed an "interface" of sorts that can be used by aspects
> and those aspects can remain very generic and reusable.
> <shameless-plug>I did something very similar to this in
> Contract4J (http://www.contract4j.org), which I discussed at
> AOSD.06 in an Industry Track paper
> and also a workshop paper
More information about the discuss