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

["Gregor Kiczales" <gregor@xxxxxxxxx>]

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
>