J J wrote:
Interfaces in Java are mostly just a pain IMO. They provide a few extra protections here and there, and give the programmer hints as he browses the code, but since you can't add a default implementation to them they just enforce a certain level of code duplication. At least in my experience and most of the Java programmers I know (admittedly not the whole world).
The main problem is the (mostly) static nature of interfaces in Java. E.g., declaring them is a pain, otherwise I would disagree. If you want to share a default implementation use a subclass - one of the big problems I see with traits is that their interfaces get so specific that an *alternative* implementation becomes effectively impossible (therefore completely loosing the point about interfaces as abstractions).
For example, look at TAccessingMethodDictDescription (which is simply the first in the browser) - it is practically impossible to reimplement this (or any other) of the current traits for the class kernel in any way that doesn't exactly follow the current implementation (like if TAMD is responsible for accessing the method dictionary then we should be able to reimplement MD access without affecting any other trait, right?).
As I see it, there are *way* too many dependencies between these traits and interfaces can help to abstract from these dependencies. For sharing (default or not) implementation, Java (as well as Squeak) has a single inheritance tree which works for almost all purposes just fine. If you use delegation instead of inheritance it works for *everything* just fine and, IMO, typically results in a better set of collaborators because suddenly these roles become objects themselves.
So from a usefulness point of view I think Traits already should be better, and once the tools support them they will give the same hints the Java implementation does at least.
Early on I thought the same way (and this was why we started thinking down that road when Nathanael interned with us). However, in practice it seems like Traits are mostly being used as a thinly veiled version of MI with all the same problems. You have correctly pointed out that Java interfaces are "nothing but abstract virtual base classes in C++" - which coincidentally, was the only way that MI ever worked in C++, which itself has two dozen ways of doing MI wrong and exactly ONE to do it right (abstract virtual base classes). Java choose a stand on that and it worked (which is pretty impressive given that it was the first language that used interface to that extent). Traits seem to reintroduce a number of ways of using MI wrongly (at least that's the feeling that I get when I look at the practical example) and that's why I prefer interfaces.
Cheers, - Andreas