Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] New intertype syntax ...new meaning?

Hi Hermann,

i was waiting for you to comment on this discussion :)  Thanks for
your thoughts!

2009/11/26 Ichthyostega <prg@xxxxxxxxxxxxxxx>:
> the longer this discussion about inlining goes on, the more it makes
> me feel queasy. It may well be that a thousand users find it "convenient"
> -- but it seems you're about to kill one of the core points in OO:
> ENCAPSULATION.

Not quite sure that is true, inlining wouldn't affect the AspectJ
rules in effect at compile time, but not sure I've made the clear
before now.  more below...

> Private is private. If I have a private variable, I *do not* want to
> have to think of any sideeffects. If I introduce a private variable
> by means of an aspect, the precise reason why I don't just modify
> the target class is -- guess what -- I *do not* want to have to
> consider all cross relations, side effects and the like and
> I *do not* want anyone outside the controlled scope of the
> Aspect to start relying on the new element. Otherwise
> I would have made it public.
>
> To put it in a different way: using an aspect helps reducing
> the programmers "mental processing load" and helps reducing
> the "in project communication" load.
>
> I am myself a programmer and often enough find myself wanting
> things to be "convenient", at hand, all in one single global bag,
> everything an java.lang.Object etc.
> But my own experience tells me that this demand is almost ever
> misguided and probably one of the key reasons for problems downstream.
>
> I am well aware that there is some sort of ongoing tendency to subvert
> strict typing, do away with encapsulation, glorify plain C programming.
> That's indeed an interesting observation, as it is directed against
> the key achievements of our craft, the few things that really brought
> us ahead in the last 25 years.
>
> But may I remind you that any long-term surviving language was successful
> only because of the ability to reject users "demands" and keep up a core vision?
>
> For AspectJ adoption, I found one of the greatest impediments to be
> people's fear, things could be "sneaked in" by aspects. The possibility
> of "an aspect" doing magic things. I witnessed in various contexts the
> antagonists to become even sort-of obsessed and immediately suspect
> "an aspect" to be the reason for any unexplainable problem.

I also see it hurting adoption that the woven class file contains
'stuff' that mean other frameworks cannot interpret the code.  As you
can see I'm trying to strike a balance between the expectations of
existing AspectJ users (and sticking to the AspectJ principals) and
what I can do to help increase adoption and keep these other
frameworks/tools happy.  I'm keeping all the discussion public here
and I really appreciate everyone helping get the design right - I will
not violate AspectJ principals that have served so well for all these
years.

> On the other hand, I see one of the key strengths of AspectJ in the
> fact, that it is easier to write a "clean aspect" working against
> interfaces with strict typing, than it is to write an "patching
> aspect" targeting internals of the implementation.
>
> - please keep the semantics of existing ITD syntax and maybe-to-be added
>  new block ITD syntax as similar as possible. Don't introduce non-obvious
>  variations in behaviour.

>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.
- after the initial compilation, further binary weaves or reweaves may
not be able to tell that ITDs were used (although not 100% thought
this part through yet - it is possible they could with a big
bunch-o-work on my part).

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.  What I'm really
talking about changing here is merely the resulting bytecode
representation of what you express as ITDs.

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
int i = m;

and it will continue to do so even in the face of inlining/less-mangling.

it is just that in the bytecode instead of seeing this for the ITD:

public int ajc$interField$X$m;

you would see

private int m;

*if* you dug about with javap.

(It often surprises people that the member we do introduce is actually
public in the target type, even though the ITD was expressed as
private.  This does mean that today any java projects consuming the
type may well see ajc$blahblah as a horrid code completion suggestion
if working with instances of that type - so in some respects, changing
it to properly private is a good thing to do anyway...)

> - please keep the mangled private names the default and require a active
>  statement by the user to request breaking encapsulation. For example
>  by an annotation on each private field which is not really private
>  to the aspect.

I think, again, you shouldn't worry too much here - the private field
in the aspect *will* only be accessible to code inside the aspect
during compilation.  I'm only affecting the bytecode format here.

> What about allowing only privileged aspects to introduce non-mangled fields?

That is a very interesting way to trigger the behaviour.  I had
thought about requiring annotations (deliberately avoiding yet another
keyword as that adds to the parser/compiler changes), but I think I
could see this triggered by privileged - after all that is already
expressing an intent to violate encapsulation and access internal
state of the target.

keep the discussion going!

cheers,
Andy


Back to the top