Re: [aspectj-users] On aspects inheritance

[Alexandre Vasseur <avasseur@xxxxxxxxx>]

Hi

Let take an example as if the following was supported:
(pseudo code)

aspect A {
   before() : execution(* X.x()) {
      //doA
   }
}

aspect ChildA extends A {
   before() : execution(* X.x()) {
       //doChildB
   }
}

Lets discuss this sample.
First, we cannot talk about an advice overriding, despite both advice
there are bound to the same pointcut, and have the same signature.
Second, if we even could do that, should you have an override, or both
advice applied ? If we apply both advices, what should happen for an
around advice ?

Also consider the following with the alternative plain Java syntax
from AJ 5 (once again as if the following was supported:)

@Aspect class A {
   @Before("execution(* X.x())") void before() {
      //doA
   }
}
@Aspect class ChildA extends A {
   @Before("execution(* X.x())") void before() {
      //doChildA
   }
}

In this case from an OO perspective there is a method overriding. Once
again, what would that mean from an advice perspective ? What would
you expect from the weaved program X ?

I invite you to define what kind of aspect inheritance you would like
to have, and point the limitations of the current approach, as well as
describing use cases that would require such a mechanism.

Alex




  

On 5/14/05, Framerlo <framerlo@xxxxxxxx> wrote:
> Hi all,
> We are two graduate students at Politecnico di Milano, Italy.
> 
> We are involved in an investigation related to AOP for one of our courses,
> and we are currently analyzing AspectJ but we got stuck reasoning about
> extending aspects.
> 
> Our problem is related to how this capability of AspectJ can be considered.
> We found that one can extend an abstract aspect, but not a concrete one. In
> particular, I can extend an abstract aspect with another (abstract) aspect,
> adding some new members (advices, pointcuts) and overriding the existing
> pointcuts. We were asking urselves how this language feature can be related
> to classic object oriented class inheritance. That is, if in OOP the
> substitutability principle holds, is it still valid in AOP? Can we speak
> about some kind of "aspect inheritance"?
> 
> Our first conclusion is that aspect extension has been provided just to
> allow some kind of code reusability: that is one should write the behavioral
> part of the aspect only once, and subsequently "bind" it to a specific
> program providing the concrete specification of the abstract pointcuts. This
> is justified by the fact that concrete aspects cannot be extended.
> 
> With respect to this, we were also wondering on how AspectJ has been
> designed without giving the programmer the ability to extend a concrete
> aspect. Is that just because the language does not provide runtime weaving
> capabilities by design, thus forcing the programmer to choose the aspects to
> be applied to the program only at compile (or load) time? We think that this
> could be some kind of correct reason...
> 
> We posted this reasoning in the hope that someone can help us to clarify our
> uncertainties about the most theoretical points on how AspectJ was designed
> and why :)
> 
> Thanks in advance
> 
> Francesco and Matteo
>  --
>  Email.it, the professional e-mail, gratis per te: http://www.email.it/f
> 
>  Sponsor:
>  Giornata faticosa? Rilassati con il Cuscino per Massaggi che vibra!
>  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2742&d=20050514
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>