[aosd-discuss] Scope of AOP..

[Marc Eaddy]

Hi Dean,

	Great point!  Using Gregor's terminology, "Event" is used as an
"annotation property" whereas "Log" is an "annotation call" [1].  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.

Cheers,

\\Marc

[1] 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
> (http://aosd.net/2006/archive/AOSD06%20-%20Industry%20Track%20
> Proceedings.pdf)
> and also a workshop paper
> (http://www.aosd.net/workshops/acp4is/2006/papers.html).</sham
> eless-plug>
> 
> Dean
>