------------Original Message------------
From: Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Sun, Jan-9-2005 3:06 PM
Subject: [aspectj-users] Doc bug/clarification? (And why is it an
implementation limitation?)
Hi,
I crashed into the "pertarget implementation limitation" today and I
was wondering if it couldn't be made a little clearer in the docs.
Although, on third read, the docs do indicate that pertarget won't
work
on objects you don't control, it isn't intuitive that it should work
that way and the one sentence "Similar restrictions apply to pertarget
aspects." is easy to miss. I suggest that the paragraph be replaced:
original:
<<
Aspects that are defined perthis or pertarget also have
restrictions
based on control of the code. In particular, at a join point where
the
bytecode for the currently executing object is not available, an
aspect defined perthis of that join point will not be associated. So
aspects defined perthis(Object) will not create aspect instances for
every object unless Objectis part of the compile. Similar
restrictions
apply to pertarget aspects.
suggested:
<<
Aspects that are defined perthis or pertarget also have restrictions
based on control of the code. In particular, at a join point where
the
bytecode for the currently executing object is not available, an
aspect defined perthis of that join point will not be associated.
Similarly, at a join point where the bytecode for the target object is
not available, an aspect defined pertarget of that join point will not
be associated. So an aspect defined perthis(this(Object)) will not
create aspect instances for every object unless Object is part of
the
compile. Similarly, an aspect defined pertarget(target(InputStream))
will not create aspect instances unless the bytecode for InputStream
is
woven into.
I think this is clearer because I'm used to thinking of this() and
execution() as vulnerable to code control limitations but call() and
target() as being more robust. (yes, I know that's a
simplification...)
Since pertarget() is implemented by weaving into the potential target
objects, it behaves a little differently than a call() && target()
pair.
Also, is it possible or advisable to allow a fallback implementation
strategy that uses a hashmap association (*) between an aspect and a
target when the target is not exposed to the weaver? Are there any
obvious problems with that?
Oh, and if we can't have the fallback strategy, could we instead have
a
warning that says something like: "no potential targets detected for
this pertarget declaration (implementation limitation)". Since the
weaver must decide which targets to weave into, it must be able to
know
if there aren't any.
* And by hashmap I obviously mean weak-reference/identity/threadsafe
hashmap
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
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
