|
Hi!
An
optimization of if(false) is just what I submitted to Bugzilla today (FastMatch)
so it's a bit coincidental that this is coming up right today cause I was
thinking about the very same problem today.
I
have seen that the use of "somePointcut() && if(false)" is a commonly
used idiom in order to deactivate certain code for debugging etc. Thus if(false)
should be considered separately and should not generate a dynamic "check" at
all. That's what my small patch leads to. So something like
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
PGP key: http://www.bodden.de/pub_key.asc
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.
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
|
