[aspectj-dev] Outcomings or not-outcomings of the perobjects BOF

["Eric Bodden" <eric@xxxxxxxxx>]

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