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

[Ganesh Sittampalam <ganesh@xxxxxxxx>]

I would be wary of such a suggestion. There's a danger of creating
confusion between the model of join points, which is essentially dynamic
even if some can be determined statically, and the notion of lexical
containment.

For example, the thisEnclosingJoinPointStaticPart for join points such as
calls that occur within constructor preinitialization is the same join
point, not that of the preinitialization (I'm not sure why). So either
such calls should not be covered by within(preinitialization(...)), or the
notion of containment for thisEnclosingJoinPointStaticPart will not be the
same as for within(..). Either would be confusing [I guess the current
behaviour of thisEnclosingJoinPointStaticPart could be changed instead].

Cheers,

Ganesh

On Wed, 22 Dec 2004, Ramnivas Laddad 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
>