[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-dev] Use of non-statically resolvable pointcut designators in declare error/warning.
|
> Today users often write dummy advice
to get the AJ tools to
> determine possible matches of dynamic PCDs (to find the shadow). Why
> not allow dynamic pointcuts but warn that it's only a possible match?
We hope to have direct support in the
tools (AJDT) for asking what a pointcut matches (or could match) soon.
This is planned to show up as a defered-evaluation cross-reference in the
cross-reference view (ie we won't evaluate the matches unless a user explicitly
requests it). If we do put this in, it will have to differentiate between
definite and possible matches in some way.
I'm less keen on putting out compilation
warnings that might not really be so - and as Jim has pointed out, that
would involve a deal more implementation work at this point in time too,
since the original design was not intended to cover that scenario. If we
ever are to do it, I think that would have to be a carefully considered
language change in the post 1.2 timeframe.
-- Adrian
Adrian_Colyer@xxxxxxxxxx
| "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
Sent by: aspectj-dev-admin@xxxxxxxxxxx
23/02/2004 18:53
Please respond to aspectj-dev
|
To:
aspectj-dev@xxxxxxxxxxx
cc:
Subject:
RE: [aspectj-dev] Use of non-statically
resolvable pointcut designators in declare error/warning. |
It seems to me that it would be more useful
to produce 3 kinds of results when matching declare warning/error at a
given shadow:
1) never matches
2) always matches - emit warning/error
3) possible match - emit warning, possible
warning/error: output of declare .. this is the case where there is a dynamic
check (I won't say anything about residue!)
Today users often write dummy advice to get
the AJ tools to determine possible matches of dynamic PCDs (to find the
shadow). Why not allow dynamic pointcuts but warn that it's only a possible
match?
This strategy also allows for incremental
improvement over time (e.g., if the weaver optimizes if(false) to never
match).
Ron Bodkin
Chief Technology Officer
New Aspects of Software
m: (415) 509-2895
------------Original Message------------
From: "Gregor Kiczales" <gregor@xxxxxxxxx>
To: <aspectj-dev@xxxxxxxxxxx>
Date: Mon, Feb-23-2004 9:45 AM
Subject: RE: [aspectj-dev] Use of non-statically
resolvable pointcut designators in declare error/warning.
I agree.
The circumstances under which
a dynamic pointcut can be statically resolved are too subtle to have that
be an explicit part of the language, at least for now.
-----Original Message-----
From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx]
On Behalf Of Jim Hugunin
Sent: February 23, 2004 9:33 AM
To: aspectj-dev@xxxxxxxxxxx
Subject: RE: [aspectj-dev] Use of non-statically resolvable pointcut
designators in declare error/warning.
In the 1.0 language design
we decided that you could only use statically resolvable pcds in declare
eow statements. It’s possible that this didn’t make it into the
docs, but this was a clear part of the language design for 1.0.
The 1.0 version of ajc would
detect any use of if, cflow, this, target or args for a declare eow and
produce a compile time error. Apparently, when we did the re-write
for 1.1, we neglected to include this error check.
I think that for 1.2 we should
restore the simple error check of 1.0 that forbids the use of these non-statically
resolvable pcds. This might break some existing programs that are
“getting away with it”, but that seems a small price to pay for keeping
this simple and understandable rule about what can and can’t be used in
declare eow. Any programs that might break will do so in a clear
and unambiguous way with this new error message, so it won’t cause any
subtle problems for people.
If you decide to allow the
special cases where this, target and args ARE statically determinable you’ll
have to go through the implementation and make sure that’s what you’re
doing. The current implementation was not designed to support this
because I had assumed that the original test from 1.1 prohibiting any use
of these pcds in declare eow was in place.
BTW – dynamic residue is a
term used for the implementation of AspectJ. It’s used in Erik’s
and my implementation paper. I think it does a great job of describing
the runtime tests that can be left over when weaving join point shadows
in the implementation. This term was never intended for user-level
docs.
-Jim
From: aspectj-dev-admin@xxxxxxxxxxx
[mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Adrian Colyer
Sent: Monday, February 23, 2004 9:05 AM
To: aspectj-dev@xxxxxxxxxxx
Subject: Re: [aspectj-dev] Use of non-statically resolvable pointcut
designators in declare error/warning.
As a follow-up - Andy & I went searching all through our docs looking
for the place where we say that you can only use statically evaluable pointcuts
in declare eow statements, but I couldn't find it clearly stated anywhere.
(I half recall seeing a list that said "You can only use the following
pcds..." but if it's there, I couldn't find it).
I think the simplest thing for users to understand is a compilation error
if any of this, target, args, cflow, cflowbelow or 'if' are used in the
pointcut _expression_ associated with a deow. But, this might break many
existing programs that are currently "getting away with it."
The next best option seems to me to be to emit a compiler warning saying
that "xxx pcd cannot be used in declare error or warning statements
and will be ignored." (And then of course, make sure that we really
do ignore it). Given our current position, this is possibly what we should
do for 1.2 (leaving us the option to make it an error in 1.3 once programs
have been tidied up perhaps?).
Both of these options have the drawback of not supporting some deow tests
that would have succumbed to full static evaluation. If that's important
enough, we could consider warning only when a non-statically determinable
situation occurs - but what I dislike about this option is that this can't
be determined when compiling the aspect, but only during shadow matching
(which could be at a completely different time if e.g. you are binary weaving).
So I think at the moment I'm leaning towards:=
1) making the docs clearer about exactly which pcds are supported for deow,
and
2) following a warn-and-ignore strategy for violations of that policy
Open to counter-arguments though...
-- Adrian
Adrian_Colyer@xxxxxxxxxx
| Andrew Clement/UK/IBM@IBMGB
Sent by: aspectj-dev-admin@xxxxxxxxxxx
23/02/2004 16:16
Please respond to aspectj-dev
|
To: aspectj-dev@xxxxxxxxxxx
cc:
Subject: [aspectj-dev]
Use of non-statically resolvable pointcut designators in declare error/warning. |
Hi,
I'm looking at a bug on this - and I noticed someone else mailed
the list on a similar topic earlier today.
Eric Bodden reported a problem with using if() in a declare
warning/error message. This was a ClassCastException - which of
course I'll fix - but it made me think more about what our
position is on allowing users to use pointcuts that can't
be wholely resolved at compile time with the declare error/warning
mechanism.
At the moment, if a pointcut cannot be entirely statically
evaluated then it will behave as if it has matched and the error
or warning message will be produced. I don't think this is
quite what we want.
However, it is not clear whether we should be flagging an
error if any of the designators that exhibit this behavior
are used against declare error/warning or if we should be
flagging an error/warning if it just the case that the entire
pointcut cannot be completely resolved statically. There are
some designators that *could* lead to runtime tests but might
not if there is enough static info around. For example
target()/this() may or may not create an instanceof test for
execution at runtime depending on what the compiler can
determine statically.
So, we have the options:
Error/Warning if we see a declare error/warning statement whose
pointcut uses any of the designators that *might*
lead to dynamic residue.
Error/Warning if we see a declare error/warning statement whose
pointcut cannot be completely statically evaluated.
Any comments?
Andy.
---
Andy Clement
AJDT/AspectJ Development