Re: [aspectj-dev] pertypewithin() vs. pertype() association...

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

Hi All -

Ramnivas, re: 

> - The first join point encountered is the one matched by 
> staticinitialization(TypePattern)

As Jim points out in the bug, this is not always the case :(

Adrian, re:
> >...the enclosing type of a join point shadow is 
> >probably the right answer as Jim suggested

which is to say

  thisEnclosingJoinPointStaticPart.getSignature()
    .getDeclaringType()

, right?

Adrian, is it fair (or helpful?) to say that

  pertypewithin(TypePattern)

is syntactic sugar for

  pertype(within(TypePattern) 
      && (staticinitialization(*) || execution(static * *(..))))

(the only form we'd like to support now)?

Eric, re: 
> The problem arises
> for me, as soon as people start reasoning about expressions like
> pertype(call(* Foo.bar())). It's not quite straightforward here, what 
> type
> is meant: Do we get an instance for the calling type or the caller type 
> - or
> maybe even for both.

Using the pertype(Pointcut) form might enable developers to 
also associate aspects with the declaring types of references 
used to call, get, or set.  e.g.,

   aspect A pertype(target(SecurityManager))
       Logger logger = ...;
       before() : call(* *(..)) {
           // log all calls to any SecurityManager to same log
       }
   }

This would *not* be implemented using the enclosing type but
using the declaring type of the signature itself.  (The enclosing
type and declaring type are the same for the join points that 
don't roam ({static|pre}initialization, {advice}execution, handler).
They differ for the roaming join points (call, get, set).)  

As with call join points, developers would have to remember that
it's the declaring type of the reference, not the referent. And
since the reference/declaring type here can be an interface, it
raises the question how those would be implemented, and whether
developers would again have to factor in limitations due to code 
the implementation controls.

Personally, I'm strongly biased initially to keep the pointcut
form (partly in anticipation of better tools for correlating
and simplifying pointcuts directly), but these issues lead me
down the path proposed by Adrian, et al, which I think focuses
more on usability and the common use-cases, and allows us to 
later generalize pertypewithin(TypePattern) to pertype(Pointcut).

Wes

P.S. - Eric, re:
> The major drawback as you
> mentioned turns out to be "sub-aspecting". 

This could be a whole topic unto itself: when is narrowing,
widening, or otherwise changing instantiation sensible,
and when should it provoke warnings or be restricted.
In some cases, superaspects might rely upon the scopes
they define and wish to restrict the ability of subaspects
to change the scope. hmm:

  abstract aspect A requires percflow(pc()) { .. }

P.P.S. - Eric, re:
> I have actually found
> quite some use cases where you want to associate aspect instances with 
> a certain object which is *not* necessarily exposed through a given 
> pointcut.

It would be useful to post about these cases, at least to 
see if there are any workarounds.

> ------------Original Message------------
> From: Eric Bodden <eric@xxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Tue, Jan-25-2005 9:50 AM
> Subject: Re: [aspectj-dev] pertypewithin() vs. pertype() association...
>
> ----- Original Message ----- 
> From: "Adrian Colyer" <adrian_colyer@xxxxxxxxxx>
> > You make a good case for the pros of the PointcutDesignator form. The
> > design as documented (and mostly implemented in the tree) was a 
> compromise
> > between the (A) and (B) designs in the bug report.
> 
> > I'd like to hear the opinions of others on this point too, so please 
> jump
> > in if you have an opinion one way or the other...
> Well, since you asked for it...
> 
> I certainly would not very much go for option (B), which would allow 
> *any*
> pointcut in a pertype-clause if I understood correctly. The problem 
> arises
> for me, as soon as people start reasoning about expressions like
> pertype(call(* Foo.bar())). It's not quite straightforward here, what 
> type
> is meant: Do we get an instance for the calling type or the caller type 
> - or
> maybe even for both.
> 
> >From the simplicity point of view, my personal opinion is that
> pertypewithin(<TypePattern>) would be best. The major drawback as you
> mentioned turns out to be "sub-aspecting". But if it was possible to 
> have
> subclasses define their own pertype-instantiation, I guess that would 
> be a
> good compromise.
> 
> Another question I had in mind was if you also considered *perobject*
> instantiation rather than pertype, as proposed in the "association 
> aspects"
> paper (http://portal.acm.org/citation.cfm?id=976275). I have actually 
> found
> quite some use cases where you want to associate aspect instances with 
> a
> certain object which is *not* necessarily exposed through a given 
> pointcut.
> One such use case is for example where you want to track the state of a
> certain object in order to perform validation on it or something 
> similar.
> percflow/perthis/pertarget sometimes turn out to be "too weak" for 
> this.
> 
> Hope that helps,
> 
> Eric
> 
> --
> Eric Bodden
> RWTH Aachen University
> 
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>