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