Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] The semantics of abstract aspects : proposed changein AspectJ 5

Adrian,
 
Thanks for the explaination. I just want you to know that when I reported the issue, there are two concrete aspects derived from OrderDecorator in the project, so this might be a bug in M3a according to your explaination. ( "or adding a concrete sub-aspect of OrderDecorator would all make the program behave as desired")
 
thanks
 
guofeng
 

________________________________

From: aspectj-users-bounces@xxxxxxxxxxx on behalf of Adrian Colyer
Sent: Thu 9/8/2005 9:19 PM
To: AspectJ developer discussions; aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] The semantics of abstract aspects : proposed changein AspectJ 5



Earlier this week Guofeng Zhang posted a program to this list that
wasn't working as expected.  On investigating, I realised that there
is an important semantic issue at stake concerning abstract aspects.
I'm proposing a change to the language semantics in this area in
AspectJ 5 (which happens to be implemented in M3!) which I'd like to
put forward for discussion.

The issue concerns which statements in an abstract aspect take effect
in isolation, and which only take effect in the context of a concrete
sub-aspect. As you may recall, advice, declare error, declare warning,
and declare soft statements only ever take effect in the context of a
concrete sub-aspect.

For example, the program:

abstract aspect A {

  pointcut p() : execution(* foo()) ;

  declare warning :  p() : "some warning";

}

class C {

  public void foo() {}

}

does not issue a warning for the execution join point of foo(),
whereas if A was concrete, or a concrete sub-aspect of A was added to
the program, it would.

The reason is that these statements are all pattern (pointcut) based.
Any named pointcut declared in the abstract aspect and that they refer
to may be abstract (and made concrete in the sub-aspect), or it may be
overriden in the sub-aspect.

Prior to AspectJ 5, declare parents and declare precedence statements
in abstract aspects took immediate effect even if no concrete
sub-aspect was ever introduced into the system.  These statements are
also *pattern* based, but they are not *pointcut* based. Looking to
the future, we are considering the introduction of named type patterns
to the language, that would support composition (as today) and
abstraction (naming, and the ability to declare an abstract type
pattern).  This brings into play the same issues as previously
discussed for the pointcut-based statements, and makes it desirable to
only bind these statements in the context of a concrete sub-aspect.

The reason for making the change now is that we propose to allow type
variables to be used as absolute types in type patterns for generic
abstract aspects (see  the AJDK notebook).  Given the aspect

abstract aspect A<T> {

  declare parents : T implements SomeInterface;

}

it is impossible to give meaning to the declare parents statement
solely in the context of the abstract aspect. The type variable T here
is acting like an abstract named type pattern.

In the context of the aspect

aspect B extends A<MyClass> { .... }

the declare parents statement in A is concretized to declare that
MyClass implements SomeInterface.

The impact of this change is that any program relying on a declare
parents (or declare precedence, but this is much less of an issue I
suspect) statement taking effect in an abstract aspect that is never
concretized will break. I suspect there are not many such programs.

Guefeng posted one such program though:

public abstract class Order {
     public void print() { ......  }
}

public class SalesOrder {
}

public abstract aspect OrderDecorator
{
   declare parents : SalesOrder extends Order;
   public void SalesOrder.print()
   {
      super.print();  //  Line 12
   }
}

which produces an error at the indicated line saying that print() is
not defined for Object (the type of super when the declare parents
statement is not in effect). Making OrderDecorator concrete, moving
the declare parents statement out of OrderDecorator and into an
independent concrete aspect, or adding a concrete sub-aspect of
OrderDecorator would all make the program behave as desired.

The advantages of the change are that we can support named type
patterns in the future, and the use of type variables from generic
abstract aspects in declare statements in AJ 5.

In summary, the proposal is that any pattern-based statement in an
abstract aspect (all aspectj specific members other than inter-type
declarations) only take effect in the context of  a concrete
sub-aspect.  I welcome feedback on this proposal, particularly if you
disagree with it!

Regards, Adrian.

-- Adrian
adrian.colyer@xxxxxxxxx
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users



<<winmail.dat>>


Back to the top