Re: [aspectj-users] A question about perObjectField - instance variables

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

For per-object associations, this implementation I believe adds a
field to each class that could be associated (and might calculate
"could be" too broadly).

As a workaround, what happens if you use within() to constrain the 
pointcut?  e.g., 

  protected pointcut mutatorOperations() :  within(CacheTestHelper+)
      && execution(void CacheTestHelper.mutatorOperation());

(though you said that advice on the pointcut was not shown in 
classes affected by the perthis aspect)

Wes

> ------------Original Message------------
> From: "Antti Karanta" <antti.karanta@xxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Wed, Sep-29-2004 5:35 AM
> Subject: [aspectj-users] A question about perObjectField - instance variables generated by ajc
>
> 
> 
>                        Hi!
> 
>   While debugging my project w/ Eclipse 3.0.1 / AJDT 1.1.12 (works 
> great
> BTW, thank you AJDT team!) I noticed a strange thing. A lot of my
> classes (all?) seemed to have been injected with fields like this (this
> is copy pasted from debugger's expressions view):
> 
> CacheTestHelper$Cache
> ajc$fi_napa_util_aspects_CacheTestHelper$Cache$perObjectField= null
> 
>   Now I do understand that sometimes the aspects may need to inject 
> some
> instance variables into the classes for e.g. perthis - association etc.
> However, most of these fields are from aspects (judging the origin by
> the name of the variables) that are totally unrelated to the classes 
> the
> variables are injected into. By unrelated I mean that the join points /
> introductions in the aspect do not affect the classes the variables are
> in (AJDT does not show any effect and the point cuts are defined so 
> they
> do not match anything in the class the variables are in). 
> 
>   E.g. in the above case, the variable is in class TableSimpleImpl and
> CacheTestHelper is a simple class (in a different package) with an 
> inner
> aspect that looks like this:
> 
>   private static aspect Cache extends CachingAspect {  // CachingAspect
> has only abstract or empty point cuts
>     protected pointcut mutatorOperations() : execution(void
> CacheTestHelper.mutatorOperation());
>     protected pointcut cachedOperations() :  execution(int
> CacheTestHelper.methodToBeCached());
>     protected pointcut equalsOperation(Object other) :
>       execution(boolean CacheTestHelper.equals(Object)) && args(other);
>   }
> 
>   The CachingAspect is associated like this (in case it makes any
> difference):
> public abstract aspect CachingAspect perthis(mutatorOperations() ||
> cachedOperations() || equalsOperation(Object)) { 
> 
> 
>   So, have I misunderstood something? If not, on what basis are the
> fields injected into the classes?
> 
> 
>   This does not affect behavior, just makes the expressions view harder
> to read as it is cluttered with the injected variables. And of course 
> it
> needlessly makes the classes larger if those variables are not really
> needed.
> 
> 
> 
>        -Antti-
> 
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>