[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[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