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

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Eric,

WRT drawing parallels between pointcuts, advice and declarations in
abstract aspects and members of abstract classes I can certainly see your
point with ITDs. They can be considered static WRT the aspect that declares
them as they execute in the context of the target class. However the model
breaks down with pointcuts. They can already be considered to be static
because they have no context, can be accessed statically when defined in
another type and the "if()" PCD can only access static members. You can
already restrict what members a pointcut matches by using "this()" or the
static/!static modifier. As for static advice it seems to have little value
other than the narrow use-case of abstract aspects. It would only be able
to access static members in the aspect that defines it including fields and
therefore not be compatible with perXXX declared aspects.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/

Eric Bodden <eric@xxxxxxxxx>@eclipse.org on 14/09/2005 15:09:02

Please respond to AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>

Sent by:    aspectj-dev-bounces@xxxxxxxxxxx


To:    "'AspectJ developer discussions'" <aspectj-dev@xxxxxxxxxxx>
cc:
Subject:    RE: [aspectj-dev] The semantics of abstract aspects :
       proposedchangein AspectJ 5


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


_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev