From a pedagogical point of view
I’m leaning towards your second suggestion. As the recent email
message indicated the current result is confusing, and the compiler could teach
this by issuing warnings for non-statically-evaluable pointcuts in declare
error/warning. If that message were provided using the Xlint mechanism
then a more advanced user could suppress it (although I don’t know what
the use case would be).
On another note, I’ve heard it more
than once now and dislike the term “dynamic residue”. There
is a slight negative connotation to “residue” and the term seems
implementation-centric rather than user-centric. I’ve often heard
users say things to the effect of “so cflow means that there is a
‘runtime check’ that determines if the advice will run”, and
in the past we’ve leaned towards using terms along those lines (e.g.
“runtime test”, “dynamic check”, ..).
Mik
From:
aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Andrew Clement
Sent: Monday, February 23, 2004 8:17 AM
To: aspectj-dev@xxxxxxxxxxx
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