[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] An unclarity in prog guide about precedences and a problem in using perthis

> >   Now, if I want A to dominate B, do I simply say
> > declare precedence : A, B; 
> Yes, that's correct. Does it help with the 
> super-aspect/sub-aspect thing 
> if I say "all advice from an instance of A has precedence 
> over advice from 
> an instance of B?". 

  Yes, this is clearer IMO. 

> And for the second question...
> With the caveat that I haven't run your code, here's what I 
> see going on: 
> the difference between the perthis statement in the abstract aspect 
> (perthis(cachedOperation())  and the perthis statement in the 
> subaspect 
> (perthis(this(CacheTestHelper)) is that the latter will match 
> any join 
> point where 'this' is bound to an instance of 
> CacheTestHelper, but the 
> former only matches "cachedOperation()" join points where 
> "this" is bound 
> to an instance of CacheTestHelper. 

  A-ha. Ok, like I suspected, I had a misunderstanding about how perthis
works. In the programming guide it says:

"If an aspect A is defined perthis(Pointcut), then one object of type A
is created for every object that is the executing object (i.e., "this")
at any of the join points picked out by Pointcut. The advice defined in
A may then run at any join point where the currently executing object
has been associated with an instance of A."

  I had interpreted this so that the pointcut given to perthis is only
used by the compiler to determine what "this" is at the join points the
point cut given as argument to perthis matches to, and that other join
points will also match if they have the same "this".

  I am still a little uncertain on how perthis works exactly. I'll
rephrase my question:

 With aspect A and point cut P:

aspect A perthis(P)

  This of course causes there to be a separate aspect instance for each
"this" matched by P. But as for the advice execution:

  Does this cause the advice defined in A to execute only if they are
bound to the same join points that are also matched by P? Naturally
those join points have to be in non-static context.
  Or is it so that advice in A bound to join points other than those
matched by P will execute if any join point matched by P has been
executed first for "this", as executing a point cut matched by P will
cause the creation of aspect instance of A associated with "this"?

> A long winded way of saying that if you change the cachedOperation() 
> pointcut definition in the concrete aspect to:
> pointcut cachedOperation() :  execution(* methodToBeCached(..)) || 
> execution(* equals(..))
>    && this(CacheTestHelper);
> then I think the test will start passing again.

  Well, what I really wanted was a way to declare the aspect perthis
association in the abstract superaspect so that it would have been
inherited into its concrete subaspects.

 But now that I understand a little better how perthis works, declaring
the aspect association in the superaspect as follows seems to do the

perthis(mutatorOperations() || cachedOperations() ||

  Thanks a lot for the answers!