-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I am much in favour of such a proposal. But lets face the problem: We like and use ITD because the need for mixins and delegates is real. Java just excluded multiple inheritance to avoid dealing with its problems, thus leaving the users alone with their problems.
Simone Gianni schrieb: > ...it's just what the user perceives. In a language that supports mixins, you > can write "Minotaur = Person + Bull" you are not adding methods to Person to > support Bull functions or method to Bull to add Person functions. ..which brings up exactly the problems haunting multiple inheritance. What toString() should apply? what hashCode() should be used? If this example lives in any halfway real-world context, chances are that both Person and Bull will provide those (given they are both complete implementations of a concept) > What you can obtain is more or less the same, but the way the user will > perceive it is not the same. In the current ITD syntax it is absolutely clear > what you are adding to which classes. And exactly this clarity (which in itself is a value) makes the current ITD syntax a bit cumbersome to use and difficult to read. Sadly, this is not an cosmetic issue. I've encountered numerous times the situation that those members of the team which aren't especially interested in AOP and AspectJ (i.e. the majority), can't grasp what's going on when looking at the source code, especially when the aspect is doing sort-of a mixin of framework functionality. On the contrary, the same users don't have any problems understanding advice and to do casual maintenance to it. > In your proposal it is still clear. In the Ramnivas proposal it somehow fades > away, making me feel we could be giving the user a wrong perception... I don't think we can't avoid the user to feel that effectively a sort of multiple inheritance is happening. Because, bottom line is, we exactly want to achieve this behaviour. Maybe in a somewhat limited fashion, which could be the distinguishing factor. Ramnivas' proposal: > declare extends: ITDInterface, ITDDefaultImpl; Dave's proposal: > declare parents: [EMAIL PROTECTED] ITDInterface+ inherits ITDDefaultImpl; My feeling is that the meaning would be more clear when the relation we try to create is expressed in something reading like a sentence. The predicate "parent(A,B)." is a well know problem :-D But the idea to comply to the existing syntax is also important. Thus: declare parents: <type pattern> extends <Classname>; BUT with the limitation that the type used in the pattern has the special form of "Interface+". This would make the limitation clear. Also, I think, the compiler should check that ITDDefaultImpl actually implements the ITDInterface in a completely plain-Java fashion. Maybe ITDDefaultImpl could be required to be abstract? Probably the private parts of ITDDefaultImpl would best be really private and not visible for the aspect, contrary to an private ITD written within the aspect body. If the aspect needs to use a special API on ITDDefaultImpl (which otherwise should not be public), then I think it would be a good idea to use package access. Does this make sense? How to deal with clashes on methods defined by multiple ITDs in this fashion? They may be related to different aspects mixing in some functionality. My gut feeling is that those problems are very real and rather tough. Hermann Vosseler -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJOEnyZbZrB6HelLIRAjhgAKC5SqYzQciJadUVzIOsJd9cib1u0QCfQ8jA ZDP8MBdVpS2fjNoelcaQ2pg= =Fn56 -----END PGP SIGNATURE----- _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
