Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Concretize abstract pointcut with subtypes

> > > The purpose is to reuse some of the advices
> > involving the abstract
> > > pointcut in the abstract aspect in concrete
> > scenarios.

In that case, define the pointcut with the correct type:

  aspect A {
    abstract pointcut apc(A a);
    before(A a) : apc(a) {...}
  }
  aspect SubA extends A {
    pointcut apc(A a) : this(a) && call(String toString());
  }   

> What I'm trying to do
> is not to overload the pointcut, but using a subtype
> for the type used in abstract pointcut, just like in
> the case of any regular Java method.

This fails:

  abstract class A {
    abstract protected void apc(A a);
  }
  class SubA extends A {
    protected void apc(SubA a) { }
  }

A method is identified by its method signature, including its 
parameter types.  If you define a method in a subclass with a 
different type than in the superclass, you are not overriding
the supertype method.  So what you tried for pointcuts
would not work when defining abstract methods.

> I know it is a syntactic error. I am just wondering if
> you know why this is prohibited. 

Actually, I don't know why a named pointcut is identified only 
by its name.  It certainly makes for a simpler implementation.
If the main goal of named pointcuts is to allow pointcut
composition, then allowing overriding might lead to confusion.
Conversely, forcing full signatures might constrain some
implementations and some compile-time optimizations.
I'd be interested in hearing from Erik/Jim/Gregor what 
they considered.

For now, users can encode the difference in the name, e.g.,

  abstract pointcut loggingA(A a);
  abstract pointcut loggingB(B b);

hth - Wes

> ------------Original Message------------
> From: Charles Zhang <zhangcharles@xxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Mon, Aug-23-2004 12:04 PM
> Subject: Re: [aspectj-users] Concretize abstract pointcut with subtypes
>
> Hi, Wes, thanks for the reply. What I'm trying to do
> is not to overload the pointcut, but using a subtype
> for the type used in abstract pointcut, just like in
> the case of any regular Java method. The reason for
> doing so is that I can write some generic advices to
> deal with supertypes and allow specific extensions.
> I know it is a syntactic error. I am just wondering if
> you know why this is prohibited. Thanks.
> 
> Charles
> --- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> 
> > The code you wrote is syntactically wrong, so I
> > assume it's
> > not a copy of your code.  But based on the
> > signature, perhaps
> > you're trying to overload the one pointcut name:
> > 
> >    Though named pointcut declarations appear
> > somewhat like method
> >    declarations, and can be overridden in
> > subaspects, they cannot 
> >    be overloaded. It is an error for two pointcuts
> > to be named 
> >    with the same name in the same class or aspect
> > declaration
> > 
> >    Programming Guide, Semantics appendix.
> > 
> > Is that the mistake made?  If not, some
> > (non-)working code that 
> > others could try to compile would help frame your
> > question.
> > 
> > hth - Wes
> > 
> > > ------------Original Message------------
> > > From: Charles Zhang <czhang@xxxxxxxxxxxxxxxx>
> > > To: aspectj-users@xxxxxxxxxxx
> > > Date: Sun, Aug-22-2004 10:16 AM
> > > Subject: [aspectj-users] Concretize abstract
> > pointcut with subtypes
> > >
> > > Hi, I wonder if this is intended or just wrongful
> > usage:
> > > class A implements some reusable functionality.
> > > class B extends class A with some specific
> > functionality.
> > > My aspect defines an abstract pointcut:
> > > abstract pointcut(A a);
> > > which is concretized in a sub-aspect as follows:
> > > pointcut(B b):call(* B.*(..))&&target(b);
> > > 
> > > The purpose is to reuse some of the advices
> > involving the abstract
> > > pointcut in the abstract aspect in concrete
> > scenarios.
> > > 
> > > This is flagged as a compiler error.
> > > 
> > > Thanks for any help.
> > > 
> > > Charles
> > > _______________________________________________




Back to the top