Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Re: [aspectj-users] Aspectj discussion (and design language issues).

Macneil Shonle wrote:
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.



    

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev


  
If I undertood you theseMatchingType means all the pointcuts that occur within the target types of this aspect. The code will become (it looks better now) :

// This is only draft-code
public SingletonAspect pertype(Singleton+)
{
   protected interface Singleton {}

   private Singleton instance;

   pointcut instanceCreation(): initialization(*.new()) && theseMatchingTypes();

   Singleton around(): instanceCreation()
   {
      if(instance==null)
      {
            instance=(Singleton)proceed();
       }
      return instance;
   } 
}

and there should be a theseMatchingObject for the perinstance keyword.

This implies changing the JoinPoint (or Signature) class adding getMatchingTypes() and getMatchingObject().


Back to the top