declare warning : if(false) : "somewarning";
will now not issue any warning any more - before it did, because every
time check was deferred to runtime.
Another question might be something like "somepointcut() &&
if(A_FINAL_FIELD)". I think this should also be allowed in a declare.
However every other if-check should be forbidden in my eyes.
A Possible enhancement would be to check the method passes to "if" if it
is completely sideffect-free. If it is, one could also allow such a
method be used in an "if". However that employs a more sophisticated
analysis of course.
So in general I would vote for Ron's suggestion, too.
Eric
--
Eric Bodden
RWTH Aachen University
ICQ UIN: 12656220
Website: http://www.bodden.de <http://www.bodden.de/>
PGP key: http://www.bodden.de/pub_key.asc
------------------------------------------------------------------------
*From:* aspectj-dev-admin@xxxxxxxxxxx
[mailto:aspectj-dev-admin@xxxxxxxxxxx] *On Behalf Of *Ron Bodkin
*Sent:* Montag, 23. Februar 2004 19:54
*To:* aspectj-dev@xxxxxxxxxxx
*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
