[aspectj-dev] Re: [aspectj-users] Aspectj discussion (and design languag

[Macneil Shonle <Macneil.Shonle@xxxxxxx>]

Hi Enrique,

Duplicating "Singleton+" seems undesirable in this case. Perhaps for a
pertype aspect a thisType or theseMatchingTypes special pointcut could
be used instead.

-Macneil

>Since this mail touches language designs issues I post it at aspect-dev 
>mail list too.
>
>" ... One additional suggestion is to make the interface, i.e. 
>Singleton, a protected inner interface of the
>pattern, i.e. SingletonAspect. ..."
>Of Course, this is better programming style.  I agree with Gregor.
>
>
>" ...Mira Mezini and I had a paper at AOSD'03 that discussed the pros 
>and cons
>of the idiom/pattern mentioned above by Gregor. In that paper we also 
>make a proposal
>on how this and similar idioms can be expressed more directly with new
>programming language constructs. This paper ("Conquering Aspects
>With Caesar") can be downloaded at http://caesarj.org ..."
>
>With a little additions in the aspectJ language, it could achieve more 
>power implementing patterns.
>I'm talking about adding two new keywords, pertype(/TypePattern)/ and 
>perinstance(/TypePattern).
>
>/The pertype keyword associates one aspect instance per class that match 
>the type pattern. It is ideal for patterns like singleton:
>
>// This is only draft-code
>public SingletonAspect pertype(Singleton+)
>{
>    protected interface Singleton {}
>
>    private Singleton instance;
>
>    pointcut instanceCreation(): initialization(Singleton+.new());
>
>    Singleton around(): instanceCreation()
>    {
>       if(instance==null)
>       {
>             instance=(Singleton)proceed();
>        }
>       return instance;
>    } 
>}
>
>public aspect MyClassIsASingleton extends SingletonAspect
>{
>    // Make MyClass implements Singleton
>    declare parents: sample.mypackage.MyClass implements Singleton;
>}
>
>As you can see this is pretty more elegant, since you don't need to use 
>a Map to track the associations of  aspects and classes.
>This could be done internally at weave time by the aspect compiler (in 
>fact other implementations, more efficient,  not using Maps could be used).
>
>The perinstance associates an aspect instance per object created whose 
>class matches the type pattern. It can be used to implements patterns 
>like subject/observer. Follows draft code for this patter using 
>perinstance (form an old mail sent to aspect-user).
>
>public abstract aspect SubjectObserverProtocol perinstance(Subject+)
>{
>    protected interface Subject {}
>    protected interface Observer {}
>
>    private Set observers = new HashSet();
>    public void notifyObservers(Event ev)
>    {
>        Iterator it=observers.iterator();
>        while(it.hasNext())
>        {
>            update((Observer)it.next(),ev);
>        }
>    }
>
>    public void addObserver(Observer o)
>    {
>        observers.add(o);
>    }
>
>    // follows point-cuts and advice to capture when is necesary to
>    // update the subject.
>
>    pointcut abstract updateObserver(Subject o,Event e);
>    protected abstract void update(Observer o,Event ev);
>
>    void after(Subject o,Event e) : updateObserver(o,e)
>    {
>       // Note the new way of getting an aspect from a particular object.
>        o.aspectOf().notifyObservers(e);
>    }
>}
>
>Note that with pertype and perinstance, introductions aren't needed 
>anymore. I feel that introductions are bad practice since they violate 
>encapsulation of  the target classes and they are not as "transparent" 
>as we would like. In http://www.cs.ubc.ca/~jan/AODPs introductions are 
>avoided too (at least that is my impression).
>
>Indeed the details of these two keywords need more ellaboration (if 
>community agree with me in adding them to the language).
>
>AspectJ needs improvements in the way it associates aspects with it's 
>targets (objects/classes/aspects that are affected by the aspect). 
>Perhaps someones thinks a better way of doing all of this but current 
>constructions, perthis, pertarget, etc. are not sufficient.
>
>
>Enrique J. Amodeo Rubio.
>
>
>