Re: [aspectj-users] within{static}initialization - was Re: [aspectj-user

[Russell Miles <russellmiles@xxxxxxx>]

I've had the same question posed to me Ramnivas, with no really good answer coming immediately to me. 

I really like your suggestion and it would make things more understandable and cohesive. Personally I'm in favor of not increasing the number of pointcut types but, as your post suggests, increasing the power of an existing pointcut (safely of course :)

Cheers,

Russ
 
On Wednesday, December 22, 2004, at 11:36PM, Ramnivas Laddad <ramnivas@xxxxxxxxxxxxxxx> wrote:

Re: Wes' within{static}initialization and Ganesh's withinadvice() pointcut suggestions:

Perhaps an alternative is to modify the within() pointcut syntax to:
within(<pointcut> or <method pattern> or <type pattern>), where the pointcut specified must be statically determinable.

I have been asked a few times during my talks about reasons for having withincode() instead of within() itself taking a method pattern in addition to a type pattern. Does anyone know the reason?

If the above proposal is implemented, I guess withincode() could be deprecated.

-Ramnivas

Ganesh Sittampalam wrote: 
On Wed, 22 Dec 2004, Wes Isberg wrote:

  
<snip>
    
I am trying to figure out if there is a special syntax for using a
withincode(<clinit>) other than:

within(TypeX) && !withincode(* TypeX.*(..)) &&
!withincode(TypeX.new(..))
      
This says, "anything in TypeX except stuff in methods and
constructors," but would also pick out instance field
initializers, adviceexecution, pre-initialization, etc.
    

pre-initialization is withincode(TypeX.new(..)), isn't it? Likewise
instance field initialization, according to ajc 1.2.1, although perhaps in
theory it shouldn't be if the initializer is outside the constructor in
source. [Since bytecode doesn't distinguish, this isn't actually possible]

  
You could continue along this vein by excluding all these
other join points.  (minor point: code not upwards-compatible
with enhanced join point model.)
    

Is it possible to exclude adviceexecution? Of course, that's only relevant
for aspects, so if TypeX is a normal class this isn't a problem.

  
I'd agree w/Ramnivas that there is a bucket here that might
be useful to scope the code that's involved in class or object
initialization.  Ironically, the code is scattered in source but a
Java compiler gathers all the initializers, etc. into one class or
instance initialization chunk of code that can be staticly scoped.

So perhaps two new "lexical" pointcuts:

  - withinstaticinitialization(TypePattern)
  Restricts the scope of the join points picked out to those join
  points associated with static (class) initialization
  within types matched by {TypePattern}.
    

That makes a lot of sense and would be easy to implement. I'd also propose
withinadvice(TypePattern), for consistency as much as anything.

  
  - withininitialization(TypePattern)
  Restricts the scope of the join points picked out to those join
  points associated with object (instance) initialization
  within types matched by {TypePattern}, including object
  initialization, preinitialization, and constructors.
    

I don't understand this one. How does it differ from
withincode(TypePattern.new(..)) ?

  
  Neither form will exclude methods that might be called
  during initialization or superclass initialization code.
  [need to comment on aspect-defined initialization code]
    

I don't understand what you mean here.

  
  /** instance field-set in initialization but outside constructors */
  set(!static * T.*) && withininitialization(T) && !within(T.new(..))
    

I'm not sure where this would ever match.

Cheers,

Ganesh

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

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