Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Re: Outcomings or not-outcomings of the perobjects BOF
Hello, I've been following this thread with interest. I have read Eric's blog and Adrian's blog too. It's clear that in AspectJ it's difficult to associate an aspect with an arbitrary set of objects. Since I think this is an important feature that occurs in real life programming I think that some change should be made to the language. Since AspectJ is my favourite AOP language I have thinked in such a change. The idea is to allow non-static inner aspects in classes, so the aspect is associated with the enclosing class' instances. I'll illustrate how this make this feature possible with an example. 

public class ComplexOperation
{
   public String getId();
   public void operate(String op) {...}
}

public class Person
{
   public String getName() {...}
}

public class CleverPerson
{
   public boolean enabled=false;
   public String message="Hey, ";
   private Person p;
   private ComplexOperation o;

   public CleverPerson(Person p, ComplexOperation o) {...}

   protected void doMessage()
   {
      if(this.enabled)
System.out.print(message+" "+this.p.getName+" performs "+this.o.getId()+"<"+msg+">"); 
   }

   protected aspect  Inner
   {
public pointcut operationExecuted(String msg): execution(public void ComplexOperation.operate(String)) && args(msg); 

      after(String msg): operationExecuted(msg)
      {
            doMessage();
      }
   }
}

// Client code
Person p=new Person("John");
ComplexOperation op1=new ComplexOperation("Sum");
ComplexOperation op2=new ComplexOperation("Sum22");
CleverPerson cp=new CleverPerson(p, op1);
cp.message="Hello,";
cp.enabled=true;
op1.operate("2+2");
A non-static inner aspect instance is associated with each CleverPerson instance. When a CleverPerson instance is GC then the inner aspect is GC too. This avoids the need for extra map fields and methods to manage mapping between objects instances and aspects instances.
I think the semantic of this change is easy to understand for most AOP programmers and avoid complicating the per-clauses in the aspects. It's very natural for OO programmers too. In fact I wondered why this can't be done in AspectJ when I started to learn it. One of my early mistakes learning AspectJ was to try this kind of constructs that I see very natural.
Other possibility is to be able to instantiate aspects in the same way objects are instantiated. In this way the above example could be simply written as: 

public aspect CleverPerson explicitinstantiation
{
   public boolean enabled=false;
   public String message="Hey, ";
   private Person p;
   private ComplexOperation o;

   public CleverPerson(Person p, ComplexOperation o) {...}
after(String msg): execution(public void ComplexOperation.operate(String)) && args(msg) 
      {
            if(this.enabled)
System.out.print(message+" "+this.p.getName+" performs "+this.o.getId()+"<"+msg+">"); 
      }
}
And the client code could remain without changes. The aspect instance should be GC as a regular object. I think this could cause more impact in the language than the former version.
Eric's proposal of an explicit perthis is interesting but I see confusing to have two versions of perthis. I don't undestand the exact semantics of such construction.
I would like to know about your opinion about this kind of changes. I can understand that it could involve major reengineering and be deferred to later versions, but I'll like to know if there will be changes in AspectJ to allow more complex aspect associations and how difficult they are. 

thanks for reading such large email,

Enrique J. Amodeo Rubio.

Ron Bodkin wrote:
I couldn't agree more. -----Original Message----- 
From: Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
Date: Thu, 17 Mar 2005 23:13:05 To:aspectj-dev@xxxxxxxxxxx 
Subject: [aspectj-dev] Re: Outcomings or not-outcomings of the perobjects BOF
After talking to the CeasarJ guys, I've determined that their model of aspect instantiation and binding represents a fertile field ideas for Aspectj to harvest from and enables several interesting use cases (including, possibly yours Eric) cleanly. That being said, I think that fully harvesting their ideas will require enough engineering, not to say conceptual effort, that I would much rather address the issue in the AspectJ6 timeframe. As a practitioner, my top priorities are speed, stability, and Java5. 


Standard disclaimer:
apologies for the terseness of this email, I'm typing with a broken wrist. 

Nicholas Lesiecki
Software Craftsman, specializing in J2EE,
Agile Methods, and aspect-oriented programming
m: 520 591-1849

Books:
* Mastering AspectJ: http://tinyurl.com/66vf
* Java Tools for Extreme Programming: http://tinyurl.com/66vt

Articles on AspectJ:
* http://tinyurl.com/66vu and http://tinyurl.com/66vv
On Mar 17, 2005, at 9:32 AM, Eric Bodden wrote:
First of all thank you all for attending. I think we had a fruitful discussion. As those of you who attended will remember in the end we were all of the *false* opinion that what I proposed - associating a vector of objects with an aspect instance - could be simulated by a container object holding the actual objects in questions.
So you could instantiate say an Equality by saying "new Equality(bit1,bit2)" which would be picked up by an aspect that binds its "perthis" instance to this equality object. Well, this instantiation model works. The problem however arises as soon as you try to actually do something useful with the associated objects: 

You would need something like...

after(Bit bit): call(Bit.set()) && target(bit) {
  //iterate over all Equality objects and pick out those holding "bit"
//for each such "equality" get the aspect with aspectOf(equality) to retrieve the correct state 
  //transform state somehow
}
As you see, this is all not really useful, since there is any no benefit left from the perobjects instantiation at all. One could also use a plain singleton aspect and a hashmap instead, which would come down to... 

after(Bit bit): call(Bit.set()) && target(bit) {
  //iterate over all Equality objects and pick out those holding "bit"
//for each such "equality" get the state associated with equality in the hashmap 
  //transform state somehow
}
So in the end it comes down to using explicitly hashmaps and so forth again.
There are special cases where you can get around it and this is actually the case when you have 1:n relationships. This is e.g. the case where you have the observer pattern: One observable holds a list of n observers. Here "perthis" etc. suffice. As soon as you have n:m or even n:m:o relationships and so forth, this won't help you at all. You *have to* use hashmaps. Even ITDs won't work with n:m since you would have n (respectively m) "overlapping" ITDs on one type.
So in the end we are back to where we started: There is no appropriate language support for those kind of things. I do understand that there might not be a lot obvious use cases as this. However i think it could still be a powerful addition to have kind of this technology, cause it can be used quite well to model relationships between roles:
Whenever certain objects stand in relationships you can just encapsulate the whole behaviour of this relationship in one simple easy-to-read aspect. "Equality" is just one small example. It could be used to model all kinds of relations, for which I can imagine also a lot of business use cases: Imagine business rules of any kind. Many of them actually model certain relations between objects (and not Classes!).
Example: Imagine a business unit with a project manager, some coders, a software architet and a QA guy. And imagine an IDE that would automatically support workflow. You could put all those people "objects" into *one* explicit relation and then have all appropriate things just done by the aspect: Whenever a coder finished a modulem the QA guy is notified. Whenever a new test has been passed, the manager is notfied, whenever requirements change, the architect is notified and so forth...
Using current AJ tehcnology you would need various perthis aspects and certainly hashmaps and/or ITDs to model this. Using some association facility you could explicitly model this by just saying something like:
new CodingTeam(aManager, new Coder[]{coder1,coder2}, aArchitect, aQAGuy); 

That would be about it.

Any comments would be highly appreciated.

Eric


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


Sent wirelessly via BlackBerry from T-Mobile.
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev

Back to the top