RE: [aspectj-dev] The semantics of abstract aspects : proposed changein

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

Alexandru,

I basically agree with you. Pointcuts are essentially static for all
important purposes. They are already accessible from a static scope (i.e.,
you don't need an instance), and you can already refer to (and advise)
concrete pointcuts defined in abstract aspects or classes (see example
below)

Eric, I don't know if you were driving at the idea of forcing static
pointcuts to always be evaluated (e.g., for side-effects in if), or forcing
static ADVICE to always execute?

abstract aspect Foo {
    public pointcut readExec() : execution(* Domain.get*(..));
... before() : readExec() { /* only woven if there's a concrete subaspect
*/}
}

aspect FooTracking {
    pointcut inReading() : cflow(Foo.readExec());
... before() : inReading() && get(* *.*) { /* always woven! */ }
}


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"?

One thing that would be desirable (as Adrian Colyer posted before) would be
to allow dynamic pointcuts where you could defer the implementation until
later (e.g., having an abstract pointcut in an interface, supply the
definition in an implementation, and yet reference these pointcuts from
outside the inheritance hierarchy. I think the problem with this concept is
that weaving is done statically in AspectJ, so it's not reasonable to have
this kind of dynamic semantics. Although having extensible pointcuts whereby
you can statically change what's included would (still!) be a great addition
to AspectJ, IMHO.

-----Original Message-----
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexandru Popescu
Sent: Wednesday, September 14, 2005 8:26 AM
To: AspectJ developer discussions
Subject: Re: [aspectj-dev] The semantics of abstract aspects : proposed
changein AspectJ 5

#: Eric Bodden changed the world a bit at a time by saying on  9/13/2005
5:53 PM :#
> Hi, Adrian.
> 
> What you wrote reminds me of a proposal I have seen earlier, which is
static
> pointcuts (and advice).
> I see the connection as follows:
> 
> In classes, static methods can access static members - regardless of the
> fact if the class is abstract or not. So on an abstract class A, you can
> call some "public static A.foo()".
> 
> I think the same should be true for aspects: It should be possible to
> declare static pointcuts (and advice?). Then one could easily argue that
> "declare <whatever>" has static scope and can access anything which is
> static. Of course, static pointcuts could have no access to
this/target/args
> (or static advice to thisjoinpoint."NonStaticPart").
> 
> Hope this helps,
> Eric
> 

Maybe my understanding is very limitted here, but I cannot see what a
"static pointcut" would mean? 
IMO just by saying that have no access to this/target/args doesn't make a
pointcut static. Moreover, 
this/target/args don't come into realization (and don't need to be realized)
at the declaration moment.

About Adrian proposal it makes a lot of sense to me at least from the point
of view of generics. 
But, maybe somebody has good examples where the immediate realization of an
abstract aspect would 
make lots of sense too ;-).

my less than .02 euroc,
:alex |.::the_mindstorm::.|
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev