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

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

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.