Re: [aspectj-dev] Dummy variables on AspectJ

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

To paraphrase Jim Hugunin many moons ago, it's easiest to evaluate
language features that are well-defined and have a compelling use case.

Another way to define the semantics of your proposal is using Java's "this":

  "this" may appear as the typepattern for the reference in the call(), set(),
  and get() PCD's.  It matches when a "this" reference is used to refer
  to the join point target.  It does not match when another kind of 
  reference is used (even if it refers to the same object as "this" would)
  or when the reference is to a static member or in a static context.

Some use cases (I can't say they're compelling or even good style):  

  declare error: !withincode(void set*(*)) && !withincode(new(..)) 
        && set(* this.*) && inScope(): 
    "setting attributes outside setters and constructors"


  void around(Object input) : args(input) && set(* com.xyz..*.*) 
      && !set(* this.*) {
    // persist attribute changes unless made via this reference
    // update dirty flag
  }
  Object around() : execution(* com.xyz..*.*(..)) {
    // if dirty, persist
  }

As for the idea of binding pattern variables, I'd first like to be 
able to name and reuse typepatterns, for clarity and to avoid mistakes:

  // poor use of declare, but you get the idea
  declare typepattern : myPackages : com.xyz..* || org.xyz..*;

  before() : execution(myPackages.new(..)) { ... }

  String around() : target(myPackages) && call(String toString()) { ... }

But as far as I remember, even this is not in the cards soon.

Wes

------------Original Message------------
From: Rodrigo Gonçalves <locomotiva_diesel@xxxxxxxxxxxx>
To: aspectj-dev@xxxxxxxxxxx
Date: Fri, Mar-11-2005 1:21 PM
Subject: [aspectj-dev] Dummy variables on AspectJ
Greetings,
I have already posted this message on aspectj-users forum but it didn't seem to be quite the right place. So I appologize for the mistake and here it is again:

There seem to be a few cases in which the use of bound pattern variables in the definition of pointcuts would be useful.  For instance, if one wants to capture all atribute sets within methods with a certain annotation, but with the restriction that the method and attribute belong to the same class.  Something like:

pointcut setsWithinAnnotatedMethod() [TypePattern class_name: *] : withincode(@Annotation* class_name.*(..)) && set(* class_name.*);

Has this ever been considered?  Do you think it would be a useful feature to have in the pointcut quantification mechanism?

Thanks a lot and best wishes
Rodrigo Gonçalves


Yahoo! Mail - Com 250MB de espaço. Abra sua conta!