I think you are right that enclosing has
always meant lexically enclosing thus far. I personally think this is much less
useful than dynamically enclosing, since any time there is a *different* lexically enclosing join point
it would also be the dynamically enclosing join point (and the enclosing one is
the same, tejpsp isn’t of much value in my experience).
I raised the question in response to
Matthew’s question because:
1) I think dynamically enclosing would be more
useful: I have wished to have dynamic enclosure for adviceexecution and execution
join points in the same kinds of contexts as I would use lexical enclosure for,
e.g., field access. One example of where I’d like this for adviceexecution
is to allow writing a security audit aspect that records audit trails for any
security aspect advice, based on the advised join point…
2) I am guessing that the implementation effort
required to support dynamic join points (not just static parts) based on lexical
enclosure would make it relatively easy to extend to dynamic enclosure
I think this is an area that is worth careful
consideration (post 5.0!) to see if a small extension might capture a number of
important use cases. This is why I raised the question, because I’m not convinced
that the right thing is to extend static join points for lexical enclosure with
dynamic join points for the same… In general, I think dynamic enclosure is
important beyond what you get from cflow for efficiency. In some cases, it
matters that a certain join point is the immediate predecessor of another. While
cflow can be used to compute it, the overhead can be fairly high when you just
want to track information about e.g., call or advised side jp’s.
It would be nice to have a thisJoinPoint pcd
like you suggest Gregor.
From:
aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Gregor Kiczales
Sent: Thursday, November 10, 2005
9:54 AM
To: 'AspectJ developer
discussions'
Subject: RE: [aspectj-dev]
thisEnclosingJoinPoint
I believe enclosing has always meant
lexically.
As I recall, when we did enclosingJP, it
was a just the smallest piece of a whole set of statically enclosing dynamic JP
stuff we talked about but didn't want to do then, include the callTo and
withinExecution pointcuts.
I'm now starting to think that we should
have made a pointcut that provided the JP. This would make it possible to do
things like:
cflow(serviceEntry() &&
thisJoinPoint(tjp)) && serviceImpl()
but its probably too late for that now.
From:
aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
Sent: Thursday, November 10, 2005
8:41 AM
To: 'AspectJ developer
discussions'
Subject: RE: [aspectj-dev]
thisEnclosingJoinPoint
This does raise the question of whether
enclosing means lexically enclosing (in which case my request wouldn’t
make sense). Admittedly, if enclosing is dynamically enclosing, then the
enclosing jp for execution would normally be call. Then again, that would be
more useful too. I think this would also be consistent with the notion of
enclosing in, e.g., the if pointcut designator…
I think it would be more helpful to mean
dynamically enclosing, which would also be in the spirit of Matthew’s
query about exposing dynamic information about the enclosing join point…
From:
aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
Sent: Thursday, November 10, 2005
7:51 AM
To: 'AspectJ
developer discussions'
Subject: RE: [aspectj-dev]
thisEnclosingJoinPoint
There are certainly some good use cases
for it. I’d also like to see the enclosing join point (static part) for
adviceexecution be defined as the advised join point…
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On
Behalf Of Matthew Webster
Sent: Thursday, November 10, 2005
2:39 AM
To: AspectJ developer discussions
Subject: [aspectj-dev]
thisEnclosingJoinPoint
We have thisJoinPoint, thisJointPointStaticPart and
thisEnclosingJoinPointStaticPart but not the dynamic form
thisEnclosingJoinPoint. Is there a reason why? Is it lack of compelling use
case or implementation issues?
Thanks
Matthew
Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley
Park, Winchester, SO21 2JN,
England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
