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