RE: [aspectj-dev] The semantics of abstract aspects : proposedchangein A

[Eric Bodden <eric@xxxxxxxxx>]

Hi all.

Ron Bodkin wrote:
> You can use final pointcuts to prevent overriding their values,
> although technically that's not quite the same thing as being static
> it's effectively equivalent. Is there any other useful thing to do
> with a "static pointcut"?   
I admit that I haven't thoroughly thought-out those things, but basically
the model I would find intuitive is the following:

Generally all members which do not need to access state of a
perthis/pertarget/perwhatever aspect should be static (either explicitly by
a "static" keyword or implicitly, or at least be able to be static - because
that's how it is defined for classes.

So what does this mean for pointcuts?
A static pointcut could only access static fields of an aspect, so no fields
which are bound "perthis", etc.

What does it mean for static advice?
Static advice can access only static pointcuts and static fields. They are
always woven, even if the aspect is abstract and there is no concrete
subaspect. (Equivalent to static methods, which can always be called, also
in abstract classes.)

What does it mean for "declare error" etc.?
Those can only access static pointcuts already today - they are just not
explicitly called static (which they maybe should).

What does it mean for "declare parents"?
same as above, only for type patterns (which are always static)

W.r.t. Adrians example this means:

abstract aspect A {

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

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

}

becomes:

abstract aspect A {

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

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

}

This declares (and ensures) that p() can be statically evaluated.
The "declare warning" will be woven, since it is a static construct
(accessing static members) - and as in Java, this is perfectly fine also for
abstract classes.
Consequently, the original example (with p() not being declared as static)
would actually become invalid (because p() could potentially use nonstatic
subpointcuts). However I see that this semantic change qwill invalidate too
many AJ programs...

Now the *good* thing about it:
Static pointcuts can *only* access other static pointcuts (which can of
course not be abstract, as in usual Java).
In my eyes that's nicely coherent with the Java semantics.

Now with respect to what Adrian proposed:

I have to admit I don't see the point.
The class...

abstract aspect A<T> {

  declare parents : T implements SomeInterface;

}

Says "for all types T, t shall implement SomeInterface".
Without any instantiation of T, there is no such T, so nothing is changed in
the hierarchy.

For an aspect...

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

...which could also be abstract ...

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

...this type parameter is set. So whenever such an aspect B is present,
MyClass should now implement SomeInterface. I *must* do so, because - as
explained above - any static member whatsoever of B could require this
property (regardless of the fact if B is abstract).

In the "SalesOrder" Program, there is no type parameter whatsoever, so
according to the semantics above, the Hierarchy is changed as it was in
earlier versions (making the program a valid program as is).

So maybe I am confusing things here but I think one must not confused "being
abstract" and "being parameterized" for a class, which are two completely
different things, because with a free type parameter, there's no way to tell
where the parents should be declared but for an abstract aspect with a
concrete type there *is*.

Hope that helps,
maybe more on the call,

Eric

-- 
Eric Bodden
Chair I2 for Programming Languages and Program Analysis
RWTH Aachen University