[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Perobject association (was: [aspectj-dev] pertypewithin() vs. pertype() association...)

> I don't have time to reply to the whole thing right now, but:
> 
> I know. I'm saying there *should be*. There's no (fundamental) reason 

Sorry.  I was too tongue-in-check overall, and I didn't mean 
to misrepresent your proposal.  I can see use cases for
caching and management if there were a terminal pointcut
and control instantiation.

Perhaps perthis and pertarget aspects could support
methods to control activation:

  /**@ return aspectOf(input) if non-null, or new aspect */
  public static A A.enableFor(Object input);

  /**@ return the aspect dissassociated from the input */
  public static A A.disableFor(Object input);
 
So an MBean could enable and then disable support for 
remote control or logging of a particular component.

To maintain the current semantics for aspectOf(Object) 
and advice in a perthis or pertarget aspect, after 
enableFor(..) returned normally but before a join point 
was reached, aspectOf(..) would return null and no advice 
would run (though enableFor(..) would return the same 
aspect instance).  

The problem I see is that if an aspect were disabled 
for an particular object, what happens when a join point 
is run again?  Create a new aspect?  So we might have
have to define or declare an activation model.  (Still 
thinking about that.)

Wes

> ------------Original Message------------
> From: Lesiecki Nicholas <ndlesiecki@xxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Fri, Jan-28-2005 2:50 PM
> Subject: Re: Perobject association (was: [aspectj-dev] pertypewithin() vs. pertype() association...)
>
> I don't have time to reply to the whole thing right now, but:
> 
> <<<
> P.S. - re:
> > The set of join points at which the aspect can become 
> > disassociated with a previously associated instance
> 
> There's no such dissociation.  It's Java; there's only 
> garbage collection!  Once Foo.aspectOf(x) returns f
> for x, it will always return f for x.  Whether any
> advice will ever run again is a whole 'nuther question.
> >>>
> 
> I know. I'm saying there *should be*. There's no (fundamental) reason 
> why
> Foo.aspectOf(x) can't start returning null again after some point.
> 
> Cheers,
> Nick
> --- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> 
> > Hi folks -
> > 
> > So instead of saying
> > 
> >   aspect A perthis(pc()) { 
> >     before(This t) : somePointcut(t) {
> >       ...
> >     }
> >   }
> > 
> > perhaps I should say, for each possible type,
> > 
> >   class PerThis {
> > 
> >      Object thisObject;
> > 
> >      private PerThis(Object o) { thisObject = o; }
> > 
> >      static aspect InitPerThis {
> >          pointcut pc() : ...;
> > 
> >          Perthis getInitPerThis(Object o) { return o.perThis; }
> > 
> >          PerThis Object.perThis; // assuming you could...
> > 
> >          before(Object) : pc() && this(o) {
> >              o.perThis = new PerThis(o);
> >          }
> >      }
> > 
> >      static aspect usePerThis {
> >         // must use "perthis(..) && " with all advice
> >         pointcut perthis(Object o) : this(o) && if(null != 
> o.perThis);
> > 
> >         before(Object o) : perthis(o) && somePointcut() {
> >           This t = (This) o;
> >           ...
> >         }
> >      }
> >   }
> > 
> > Or instead of 
> > 
> >   after() : pc() {...}
> > 
> > perhaps I should say
> > 
> >   Object around() : pc() { 
> >      try {
> >        return proceed();
> >      } finally {
> >        ...
> >      }
> >   }
> > 
> > or
> > 
> >   Proxy proxy = ...
> > 
> > I'm hearing that you can use perobject(..) to implement perthis(..) 
> > using lower-level facilities, and get more control.  What would
> > be convincing to hear about perobject(..):
> > 
> > - It's easier to use
> > - It can't be done in AspectJ today
> > - There are compelling use-cases for it
> > 
> > I agree that what's confusing about perthis(..) aspects is 
> > realizing that the pointcut for each advice in the aspect 
> > has an implicit "&& this(Type)".  
> > 
> > So where the programming guide says
> > 
> > ------------------------------
> > 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.
> > ------------------------------
> > 
> > perhaps it should say 
> > 
> > ------------------------------
> > The advice defined in A will only run at a join point ...
> > ------------------------------
> > 
> > wrt IDE's, has anyone checked whether, when AJDT lists the code 
> > advised by a particular piece of advice in a perthis aspect,
> > it omits those outside the scope of this(Type)? Also, it might
> > be nice to list, for a selected type, the per[this|target] 
> > aspects that might be associated with it.
> > 
> > Wes
> > 
> > P.S. - re:
> > > The set of join points at which the aspect can become 
> > > disassociated with a previously associated instance
> > 
> > There's no such dissociation.  It's Java; there's only 
> > garbage collection!  Once Foo.aspectOf(x) returns f
> > for x, it will always return f for x.  Whether any
> > advice will ever run again is a whole 'nuther question.
> > 
> > > ------------Original Message------------
> > > From: Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
> > > To: aspectj-dev@xxxxxxxxxxx
> > > Date: Fri, Jan-28-2005 12:05 PM
> > > Subject: Re: Perobject association (was: [aspectj-dev] 
> pertypewithin()
> > vs. pertype() association...)
> > >
> > > I like your proposal! Per(target/this) aspects currently behave 
> rather 
> > > oddly, because they mix the 4 concerns together. Separating them in 
> the
> > 
> > > 
> > > source would allow programmers to appreciate the four facets of 
> > > behavior independently. I can see some other strengths that are 
> > > currently missing:
> > > 
> > > strength 1) Association becomes advice which you can see in various 
> 
> > > cross-cutting views, step into more easily, etc.
> > > (ok, I only thought of one)
> > > 
> > > However, there are some strengths to the current approach that your 
> 
> > > proposal does not address (and I say this only because I want to 
> > > improve the proposal enough to get it accepted).
> > > 
> > > weakness 1) You could mismatch your association pointcut so that it 
> 
> > > never selected objects of the appropriate type (this is probably 
> > > livable)
> > > weakness 2) New types might match the association pointcut but not 
> > > match the per clause type(pattern?)
> > > weakness 3) the association advice would appear in an aspect whose 
> > > other advice does not apply unless the aspect has already been 
> > > associated, meaning that the association advice would need to be 
> > > demarcated as "special" somehow
> > > 
> > > Cheers,
> > > 
> > > Nicholas Lesiecki
> > > Software Craftsman, specializing in J2EE,
> > > Agile Methods, and aspect-oriented programming
> > > m: 520 591-1849
> > > 
> > > Books:
> > > * Mastering AspectJ: http://tinyurl.com/66vf
> > > * Java Tools for Extreme Programming: http://tinyurl.com/66vt
> > > 
> > > Articles on AspectJ:
> > > * http://tinyurl.com/66vu and http://tinyurl.com/66vv
> > > On Jan 28, 2005, at 10:48 AM, Eric Bodden wrote:
> > > 
> > > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > Nicholas Lesiecki wrote:
> > > >> I've been thinking about perobject aspects in the shower and 
> I've
> > > >> decided that the current perobject aspects handle several 
> concerns.
> > > >> I think it's worth dissecting them for greater clarity of 
> thinking:
> > > >>
> > > >>
> > > > [...]
> > > >> Ideally, the perobject aspects would give the programmer control
> > > >> over all four concerns. Ok, that's all I have for now. Does 
> anyone
> > > >> want to pick up this ball and run it the next few yards?
> > > >
> > > > I completely agree. Also I think that perobject asoects would
> > > > eventually yield a much clearer instantiation model. As Mira 
> Mezini
> > > > et al. showed in their CEASAR implementation, perobject aspects 
> and
> > > > percflow aspects actually completely suffice to implement all the
> > > > instantiation models we have in AspectJ today:
> > > >
> > > > aspect A perthis(<Type>) {
> > > >
> > > > }
> > > >
> > > > is nothing more than:
> > > >
> > > > aspect perobject(<Type>) {
> > > >
> > > > 	after(<Type> t) : this(t) {
> > > > 		associate(t);
> > > > 	}
> > > >
> > > > }
> > > >
> > > > Same counts for pertarget *and* the newly proposed pertype as 
> well,
> > > > given that "pertype" actually means not more than "perobject", 
> the
> > > > "object" being the metaclass <Type>.class for any newly 
> initialized
> > > > type.
> > > >
> > > > Thus in the one could even completely loose perthis, pertarget,
> > > > pertype, ... (not percflow, that'S really different), since they
> > > > actually all are just special cases of object-associated aspects! 
> In
> > > > my personal opinion that would be much clearer than today. You 
> can
> > > > associate aspects with a set of objects or with a control flow. 
> Not
> > > > more.
> > > >
> > > > If one still wants for the sake of brevity a "perthis" aspect, 
> one
> > > > could probably find a means of inheriting instantiation advice 
> (as
> > > > above) down to subaspect types in a well-defined way. So you 
> could
> > > > have a PerThis super-aspect as above and all subaspects *may* 
> have
> > 
> === message truncated ===
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>