[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] args() evaluation and around advice interaction
|
We're in agreement about why a bug should be posted...
Gregor Kiczales wrote:
> Was surprised to find out that aspectJ 1.1.1
> has no provision to advice a mix of around and
> before/after advice, all defined to have same
> parameter types.
This is an overstatement; the issue is only with
using args() with adviceexecution().
I'm confused. It seems like what's going on here is just a bug.
If the around closure isn't documented, then it shouldn't show
up in args???
Yes, it would be nice to track the programmer's source model.
But the binary model can (but doesn't necessarily) have the
around closure. The parameter is implicit in the way that
the enclosing instance is an implicit parameter to an inner
class constructor. So to implement the programmer's source
model involves special-casing or changing the bytecode model
for advice execution. We've generally tracked bytecode-driven
warts on the language as implementation limitations. So if a
bug is posted, it will be resolved by being fixed or by being
documented, as something impossible to fix in Java bytecode
or just something this implementation won't/can't do.
AspectJ does not require implementations to present
arguments at the advice execution join point in the
form they are declared in the advice, so using args(..)
on advice-execution is not recommended.
We wouldn't want to say this. Instead, we might say that
at an advice execution join point there is nothing for args
to match. Or we could say exactly what it does match. But as
much as possible, we want legal AspectJ programs to always
execute the same way. So we wouldn't say "not recommended".
AspectJ is in fact executing the same way; it's just not what
the programmer expects since s/he doesn't see the closure
in source.
The statement aims to specify current behavior (i.e., it goes
in implementation, not semantics). If we implement the
source-level programmer's model, we won't need to say anything.
Wes
