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

[Ichthyostega <prg@xxxxxxxxxxxxxxx>]

Andy Clement schrieb:
> I'm nervous about making changes to what happens for weaving todays
> ITD syntax - meaning the ongoing discussions about mangling,
> visibility, etc.  A common request I am now seeing is that users want
> completely transparent application of ITDs.  What does what mean?


Hi Andy and the others,

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.

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.

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.

Other alternative approaches like reflection and dynamic proxying
don't show this property, or to a far lesser extent. They are indeed
really pervasive, while an Aspect can be kept completely self-contained
and encapsulated.

As a conclusion, may I ask you:

- 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.

- 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.

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

Cheers,
Hermann Vosseler