Re: [aspectj-dev] New intertype syntax ...new meaning?

[Ichthyostega <prg@xxxxxxxxxxxxxxx>]

Hi Andy,

thanks for your explanations, I wasn't aware of all the fine points
and I'm now a lot less worried about that change....

> 2009/11/26 Ichthyostega <prg@xxxxxxxxxxxxxxx>:
>> -- but it seems you're about to kill one of the core points in OO: 
>> ENCAPSULATION.

Andy Clement schrieb:
> Not quite sure that is true, inlining wouldn't affect the AspectJ rules in 
> effect at compile time

> I would hope there would be *no change at all* in how AspectJ polices things 
> in terms of visibility at compile time.  You will get the same errors you get
>  today if you violate visibility rules.

While I am glad to hear that :-D
...this brings up an interesting question.

> This program:
-- A.java --
public class A {
  public void foo() {
    int i = m;
  }
}
aspect X {
  private int A.m;
}

> gives this error today:
> ajc A.java
> A.java:4 [error] The field A.m is not visible

Now the goal of the change in mangling is to make this introduced field
a first class citizen within the target class, right? Especially any
framework which inspects private members (urghs) would get the impression
that it was an integral part of the target class.

How then would you be able to continue to provide such an error message?

Let's assume we have the joyful enterprise application setup we're fighting
with at my work job recently. I.e. we have Maven, and build several components,
with library aspects "crossing the borders" to cover some aspects of
integration.

- Project Base : provides class A
- Project Lib  : contains an aspect L to ITD class A with a private field

- Project Int  : consumes the Base.jar processed by Lib. Now it contains a
                 privileged aspect which tries to access the introduced field.
                 Maybe it even processes any field of a certain type.

Not that I would dare to do such a thing ;-)
But, what would be the "right" behaviour in this situation?
>From a logical point of view? From a "least surprise" point of view?

OK, a privileged aspect can access any field anyway, but my point is that
I am not sure at all what would be desirable here. And what would be self-evident?
Along the same way of thought, why should the class itself be prevented to
access a private member, which for all other facilities in the system looks
as being a completely regular private member of this class?


Andy Clement schrieb:
> From the point of view of an AspectJ developer, right now if inlining were to
>  happen then the only changes I think the user would have to be aware of are:
>  - the meaning of the within() pointcut will change *if* it was being used to
>  differentiate between affected classes and aspects defining ITDs - not sure 
> how common this case is.
> - using 'thisJoinPoint' (and friends) for join points that relate to ITDs
> will show the declaring type to be the target and not the aspect. It really
> will be as if the aspect has completely transparently added its ITDs to the
> target.

Both seem to be more logical behaviour. But I would consider this
a "border case" anyway, so there is no clear "least surprise" behaviour.

Where *is* a ITD'd field actually living? Where does it belong to.
Without caring for the actual implementation within AspectJ, this
is difficult to tell. Thus, I think any behaviour is ok as long as
it is defined (somewhere in the manual so the user can look it up).

I would consider any use relying on such always to be somewhat tricky.


> I also see it hurting adoption that the woven class file contains 'stuff' 
> that mean other frameworks cannot interpret the code.

Hehe, sounds familiar. Just recently had the case of TestNG trying
to "run" an aspect as test case. While the purpose of the Aspect
was to ITD a @BeforeSuite method into some other test classes.

Indeed a situation where I couldn't help smiling. Because TestNG
was obviously "right" ;-) And AspectJ behaved in a sound way too IMHO.

Cheers
Hermann