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 _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
