[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-dev] interfaces, pointcuts, and libraries
|
Wow. Very interesting discoveries!
But it's a bug.
"Abstract pointcuts may only be declared
within abstract aspects"
Programming Guide, Semantics appendix
Here's my speculation as to why; Jim or Erik can
chime in on the actual reasons.
Pointcuts are resolved at weave-time, i.e., staticly,
If advice refers via an interface, it's not clear to
me which implementation should be used:
interface I {
abstract pointcut pc();
}
before () : I.pc() { ... }
class A implements I {
pointcut pc() : within(A);
}
class B implements I {
pointcut pc() : target(A);
}
If advice has to refer to implementation types,
then it doesn't seem like it's part of an interface.
It doesn't seem like this would support incremental
weaving, if the advice or aspects depended on the
number of (other) implementing classes.
For subaspects implementing abstract pointcuts,
then there is advice for each instance; could this
be a similar case? I'm not sure how.
You could do "one for each implementing class",
but that would make it hard to understand when aspects
should be instantiated. If there are two concrete aspects
using an interface reference to a pointcut that has
3 implementations, then are there 6 aspect instances?
That are created when the interface-implementation classes
are loaded? What if these are cflow aspects?
The nice thing about putting abstract pointcuts in aspects
is that the crosscutting specification is local to that
aspect hierarchy. One answer to my objections is to
restrict the scope of the interface pointcuts to the
implementations themselves, but that seems contrary to
the purpose. That can be done with abstract aspects
(except that classes can't extend them).
Wes
Adrian Colyer wrote:
AspectJ lets us declare pointcuts within aspects, classes and interfaces.
To create 'library' pointcuts I need to be able to declare pointcuts in an
interface (and let users of the library program to the interface), and
then have implementers of the interface provide concrete implementations
of those pointcuts. Exploring the behaviour of AspectJ 1.1 I see that we
are part of the way there, but not fully. What I am about to describe is
partially bug and partially feature request...
Today I can write:
public interface Foo {
public pointcut bar();
}
This compiles happily, and I can refer to Foo.bar() in advice (it doesn't
match any joinpoints).
If I write
class C implements Foo {}
this does not cause a compilation error (I believe it should, since C does
not define pointcut bar which it's interface contract says it should).
If I write
class C implements Foo {
public pointcut bar() : execution(... ...);
}
this compiles happily. Writing advice against Foo.bar does not match
anything, writing advice against C.bar() matches the execution joinpoints.
The desired behaviour is that writing advice against Foo.bar should match
against the C definition.
If I write
aspect A implements Foo {}
this does not cause a compilation error (I believe it should, since C does
not define pointcut bar()).
If I change the interface definition to
public interface Foo {
public abstract pointcut bar();
}
then compilation of A fails with "inherited abstract pointcut Foo.bar() is
not made concrete in A" (good, but tells me that the pointcut is not being
implicitly made abstract when defined in an interface). Compilation of the
empty C declaration still does not produce the compilation error.
How I think I would like this to behave is that pointcuts declared in
interfaces are implicitly abstract (just like method definitions in
interfaces). If a class or aspect declares that it implements the
interface without providing a concrete definition of the pointcut then
this is a compilation error. Clients should be able to write advice
against the interface, and the advice will apply to joinpoints matching
any of the concrete implementations of interface in the system (same
rules as for abstract / concrete aspect pairs).
Why this is important:
* I can create a standard interface that clients program to
* Multiple parties can implement the interface to provide concrete
implementations that make sense within their system. These can even be
binary so that implementation details are never exposed to clients.
What do others think?
-- Adrian
Adrian_Colyer@xxxxxxxxxx