Re: [aspectj-users] ITD syntax

[Ichthyostega <prg@xxxxxxxxxxxxxxx>]

-----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: !@FastImpl 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-----