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
