[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-dev] Outcomings or not-outcomings of the perobjects BOF

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