Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Perobject association (was: [aspectj-dev] pertypewithin() vs. pertype() association...)
I like your proposal! Per(target/this) aspects currently behave rather oddly, because they mix the 4 concerns together. Separating them in the source would allow programmers to appreciate the four facets of behavior independently. I can see some other strengths that are currently missing:
strength 1) Association becomes advice which you can see in various cross-cutting views, step into more easily, etc. 
(ok, I only thought of one)
However, there are some strengths to the current approach that your proposal does not address (and I say this only because I want to improve the proposal enough to get it accepted).
weakness 1) You could mismatch your association pointcut so that it never selected objects of the appropriate type (this is probably livable) weakness 2) New types might match the association pointcut but not match the per clause type(pattern?) weakness 3) the association advice would appear in an aspect whose other advice does not apply unless the aspect has already been associated, meaning that the association advice would need to be demarcated as "special" somehow 

Cheers,

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 Jan 28, 2005, at 10:48 AM, Eric Bodden wrote:



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicholas Lesiecki wrote:

I've been thinking about perobject aspects in the shower and I've
decided that the current perobject aspects handle several concerns.
I think it's worth dissecting them for greater clarity of thinking:



[...]

Ideally, the perobject aspects would give the programmer control
over all four concerns. Ok, that's all I have for now. Does anyone
want to pick up this ball and run it the next few yards?


I completely agree. Also I think that perobject asoects would
eventually yield a much clearer instantiation model. As Mira Mezini
et al. showed in their CEASAR implementation, perobject aspects and
percflow aspects actually completely suffice to implement all the
instantiation models we have in AspectJ today:

aspect A perthis(<Type>) {

}

is nothing more than:

aspect perobject(<Type>) {

	after(<Type> t) : this(t) {
		associate(t);
	}

}

Same counts for pertarget *and* the newly proposed pertype as well,
given that "pertype" actually means not more than "perobject", the
"object" being the metaclass <Type>.class for any newly initialized
type.

Thus in the one could even completely loose perthis, pertarget,
pertype, ... (not percflow, that'S really different), since they
actually all are just special cases of object-associated aspects! In
my personal opinion that would be much clearer than today. You can
associate aspects with a set of objects or with a control flow. Not
more.

If one still wants for the sake of brevity a "perthis" aspect, one
could probably find a means of inheriting instantiation advice (as
above) down to subaspect types in a well-defined way. So you could
have a PerThis super-aspect as above and all subaspects *may* have
the option to inherit this instantiation model. Same again for
pertarget, pertype.

Does this make sense?

Eric

- --
Eric Bodden
Chair I2 for Programming Languages and Program Analysis
RWTH Aachen University

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQfp66swiFCm7RlWCEQKhiwCfd08TMLxbQ2WozaW+Nil8RcvcoWoAoMPU
XSshRoN5eBnOig6qHEb4XNJC
=3woV
-----END PGP SIGNATURE-----


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

Back to the top