RE: [aspectj-users] Re: when final is not

["rbodkin" <rbodkin@xxxxxxxxxxxxxx>]

I'd like to see effort put into making declare error (and declare warning) a 
more effective tool for governing (and warning about) what aspects can and 
can't do, not crafting "hard coded" restrictions.

Rather than restricting what aspects can do on final classes, methods, etc. 
we should be looking to expose more relevant properties in pointcuts (such as 
isFinal() or @final and isPrivileged() or @privileged) so you can write 
declare error statements that define what is and isn't allowed in extending 
join points through pointcuts. The benefit of this approach is that pointcuts 
_can_ account for properties of join points (although more extensions would 
be needed to capture the difference between set(* Type+.*) and set(int 
Subtype.a)).

Ron

On Wed, 14 Jan 2004 08:42:56 -0800, Gregor Kiczales wrote
> I wish I had more time to write this now, but this will have to be  short.
> As such, its not as well written as it should be. Sorry!
> 
> I think there's an undercurrent of "seeing AspectJ as injecting code"
> lurking in here, that's worth trying to tease out in thinking about this.
> Its easy to get into this undercurrent, so its worth reminding ourselves
> about it from time to time.
> 
> Here's some things I notice in your message that make think this:
> 
> As soon as you explicitly talk about shadows, you're in danger of talking
> in terms of the implementation (code injection) rather than the semantics
> 
> (advising join points). It is of course possible to talk about 
> shadows and still be in semantic space, but it's a slippery slope.
> 
> Suggesting that the semantics should depend on whether source code is
> available also sounds like it is introducing an implementation issue
> into the semantics.
> 
> Also note that you're talking about advice as "affecting methods". 
> But advice doesn't affect methods, it advises join points. The whole 
> game of well done AOP is to be able to say
> 
>   - these classes do what they do
>   - these aspects do what they do
>   - a SYSTEM with both the classes and aspects therefore has
>     this compound behavior
> 
> The aspects don't "change" the classes. They advise join points or introduce
> methods, but that behavior belongs to the aspects -- even though it appears
> when the classes are called (in a certain context).
> 
> Also remember, (as I've flamed before) that whether advice on a join 
> point is reasonable depends critically on not just the properties of 
> the join point, but also the properties of the pointcut and the 
> advice. So we don't want to get into a world where a simple final 
> declaration walls off all advice. We're going to have to wait for a 
> more expressive solution to the much sought after join point 
> encapsulation issue.
> 
> Finally, I don't think we want to be able to say that "AspectJ 
> respects Java's modularity unless you explicitly declare an aspect 
> privileged". The whole gambit of AOP was that traditional modularity 
> rules were too limiting. (That's what made it hard, was to properly 
> break existing rules.)  Instead we want to say a more complex thing, 
> like "the code within advice and inter-class methods respects Java's 
> modularity unless you declare the aspect privileged". But there's no 
> way to say that introductions or pointcuts and advice respect Java's 
> modularity, because they don't.
> 
> > -----Original Message-----
> > From: aspectj-users-admin@xxxxxxxxxxx 
> > [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Wes Isberg
> > Sent: Wednesday, January 14, 2004 4:31 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] Re: when final is not
> > 
> > 
> > Good point...
> > 
> > Pointcuts are indeed not restricted by Java's access rules in what
> > they see.  Otherwise, pointcuts would pick out code inconsistently
> > (not based on their specifications) and some crosscutting behavior
> > which was intended to be advised would not be.  [Gregor I'm
> > sure has a better way of saying this.]
> > 
> > Java's access rules still apply to code (including code in
> > the if() PCD and in other code-things in the aspect, like
> > methods, initializers, constructors...), unless the aspect
> > is declared privileged.
> > 
> > Since advice can affect and skip private methods, which
> > most programmers consider as effectively final, it's not
> > clear that affecting final classes is any worse.
> > I personally found it a bit more surprising.
> > 
> > Wes
> > 
> > mmonteiro@xxxxxxxxxxxxxxxxx wrote:
> > > More than advice on final methods, it permits advice on 
> > private methods.
> > > For instance, in the code below non-privileged aspect 
> > Peeping can delete 
> > > the behaviour of the call to private method Capsule.hidden(int) and 
> > > capture its argument:
> > > ----------------------------------------------------------
> > > public class Capsule {
> > >  private void hidden(int dummy) {
> > >     System.out.println("I should be safe here...");
> > >  }
> > >  public void test() {
> > >     hidden(17);
> > >  }
> > > }
> > > public aspect Peeping {
> > >  pointcut privateCalls(): call(private void *(..));
> > >  pointcut call2Hidden(int arg): privateCalls() && args(arg);
> > >  void around(int arg): call2Hidden(arg) {
> > >     System.out.println("No, you're not safe: (" + arg + ").");
> > >  }
> > > }
> > > public class TestAccess {
> > >  public static void main(String[] args) {
> > >     Capsule capsule = new Capsule();
> > >     capsule.test();
> > >  }
> > > }
> > > ----------------------------------------------------------
> > > However, if I try to call Capsule.hidden(int) from within 
> > the Peeping's 
> > > around() advive, I get error
> > > "The method hidden(int) from the type Capsule is not visible".
> > > Someone correct me if I'm wrong, but doesn't the privilege 
> > affect only 
> > > the "pure-Java" parts of aspects (i.e. code inside advice)? 
> > It doesn't 
> > > seem to have any effect on the semantics of pointcuts and other 
> > > aspect-specific parts.
> > > 
> > >> AspectJ permits you to add members to final classes and advise
> > >> various join points whose static shadows are in final classes
> > >> without specifying that the aspect is privileged. 
> > >> Do folks think: 
> > >> a) this is ok as-is
> > >>  i) but we should implement XLint messages for this 
> > >> b) this should only work for privileged aspects 
> > >> c) this should only work when you have the source
> > >>  code for the final classes 
> > >> d) only non-public members {or some other subset} is ok
> > >>   because users of them know about the aspect 
> > >> e) this should never work 
> > >> Consider also: 
> > >> - We permit advice on field-set join points where the
> > >> field is final, and advice on the method-execution of
> > >> final methods. 
> > >> - Respecting final means that the AOP programmer who is working
> > >> on system issues can't implement a system-wide concern that
> > >> might not have been forseeable on the part of the programmer
> > >> of the final class, and in any case is not the responsibility
> > >> of the final class. 
> > >> - We'd like to be able to say things like, "AspectJ respects
> > >> Java's modularity unless you explicitly declare an aspect
> > >> privileged," in order to have a clean policy that address this
> > >> concern of newcomers. 
> > >> - We can write an XLint message so people can decide for
> > >> themselves whether it is ignored, a warning, or an error. 
> > >> Thanks -
> > >> Wes 
> > > 
> > > 
> > > Miguel J. T. Pessoa Monteiro
> > > Ph.D. student Minho University,Portugal
> > > eMail: mmonteiro@xxxxxxxxxxxx
> > > URL:http://gec.di.uminho.pt/mpm/
> > > _______________________________________________
> > > 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
> > 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users



Ron Bodkin
Chief Technology Officer
New Aspects
m: (415) 509-2895