RE: [aspectj-users] How to provide external pcd definition?

[Adrian Colyer <adrian_colyer@xxxxxxxxxx>]

>  - it's a first step towards supporting behavior reflection ala
>    metaobject protocol in AspectJ. This first step isn't integrated
>    into the language, but it has tentative connection to the 
>    implementation.

You're absolutely right of course, this is a great insight. It makes me 
think the type should be org.aspectj.lang.reflect.Pointcut, and the way to 
construct one from a string-based pointcut expression should be something 
like:

Pointcut pc = Pointcut.fromString();  (rather than a constructor)

so we have (in the first incarnation):

possibility a)

public class Pointcut {

  public static Pointcut fromString(String pointcutExpression) {}

  public boolean matches(JoinPoint jp) {}

}

or, possibility b)

public class AspectJElementFactory {

  public static Pointcut createPointcut(String pointcutExpression);

}

public interface Pointcut {

  public boolean matches(JoinPoint jp);

}

I think I'm leaning towards possibility b, because I like the notion of 
Pointcut being an interface (even though possibility (a) is closer to the 
java.lang.reflect design) - it allows for example a separate 
implementation for a Pointcut obtained via reflection (as below), and one 
constructed by a string (on the assumption that the implementation of the 
former may be more efficient at matching). If and when AspectJ supports a 
richer MOP (or even just a more complete reflection API ;) ), then you can 
imagine an interface 

public interface Aspect {

  public Pointcut getPointcut(String name, Class[] parameterTypes);

  public Pointcut[] getPointcuts();

  // ...
 
}

which is a very nice extension and totally consistent with defining the 
minimal Pointcut interface now.  It also points to the fact that Pointcuts 
should probably be immutable.

-- Adrian
Adrian_Colyer@xxxxxxxxxx



"Gregor Kiczales" <gregor@xxxxxxxxx> 
Sent by: aspectj-users-admin@xxxxxxxxxxx
12/05/2004 17:57
Please respond to
aspectj-users


To
<aspectj-users@xxxxxxxxxxx>
cc
<rod.johnson@xxxxxxxxxxxxxxx>
Subject
RE: [aspectj-users] How to provide external pcd definition?








Adrian Colyer said: 

> Firstly, a new utility class: JoinPointMatcher.  JoinPointMatcher is 
> constructed with a string (in the expected usage this is obtained
> from a config file, but it could be generated in the program itself 
> at runtime for extreme use cases) which contains an AspectJ pointcut
> expression, e.g.:
> 
> JoinPointMatcher jpm = 
>    new JoinPointMatcher("within(patterntesting..*)");
>
> At any join point, you can ask JoinPointMatcher whether or 
> not it matches: 
>  if( jpm.matches(thisJoinPoint)) ...

This is very interesting. There seems to be (at least) two ways to think
about it:

 - it's a convenience utility, that operates on JoinPoint objects,
   to help people write certain join point predicates. It currently
   happens to make use of code from the compiler.

 - it's a first step towards supporting behavior reflection ala
   metaobjec protocol in AspectJ. This first step isn't integrated
   into the language, but it has tentative connection to the 
   implementation.

As currently designed, you can take both views. The difference is in
how this plays out in the future. 

With the second approach, you could imagine going farther, and making
first class pointcuts really part of the language. The potential
advantage to doing this would be that in the future, when we have
true VM based weaving, you might get much better performance from
such a scheme than with the first approach. This is because the
implementation would have a better chance at "compiling in" a first
class pointcut when it becomes defined.

In the current approach its going to be a lot more difficult for 
that kind of optimization.

The advantage of the first approach is there is no language change
involved, and some might argue that it makes the immediate performance
costs clear.

Either way, this seems like a good first step.

It seems like it should be fairly straightforward to extend this to
allow getting access to values. So that I might say:

   ptc = Pointcut.parsePointcut("(int x): execution(void Point.setX(int)) 
&& args(x)");

then, when the pointcut matches, it could return some sort of environment
structure that says has the value of x.

But once you do this you may be stuck having to write/refactor a lot of 
code
rather than being able to conveniently glom onto the existing code in the
weaver.

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