J J wrote:
>> 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).
> 
> Does it have to be this way, or are you looking at a... less then 
> optimal use of a workable technology.

Of course it doesn't have to be that way. But one of the hardest things 
to do is to be honest about how particular features of languages 
*actually* work out. It's like MI in C++ - of course there are ways of 
using it "right" it's just nobody seems to use it that way (although I 
will admit that my experience is dated - after having burned my fingers 
several times I never used MI again other than in the Java way, that is 
by using abstract virtual base classes).

[... snip ...]
> I hear what you are saying about "use a base class", but does my base 
> class still have to say "implements"?

That depends on your particular flavor of interfaces. BTW, I do see your 
point about Haskell but note that in your example you have both given 
the definition as well as the constraint on a particular interface - in 
my understanding this is more like specifying type algebra or pre/post 
condition and not as much about actually providing the code for the 
implementation.

> Either way, this feels to me like another manifestation of a problem I 
> always had with Java:  implementation inheritance.  I may make 3 totally 
> different window widgets, and by rights each one would "implement" a 
> draw API, but I will have to invent another class for them all to 
> inherit to avoid duplicating a bunch of unrelated code.  People reading 
> my code may wonder why "3DGameWindow" is in the same tree as 
> "TaskBarClockWidget", but it is just to save code duplication.

That's why I mentioned delegation. You could have an object 
encapsulating the drawing policy and have your three classes delegate to 
it. In which case you not only get the interface but also the ability to 
dynamically change the drawing policy - at the cost of (at least) one 
slot for the object representing the policy. To me, this is a much 
cleaner way of dealing with the problem you are describing while 
preserving all of the good properties of objects.

>> 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?).
> 
> Is this a problem with the technology (Traits), or the implementation?

There is not enough evidence to draw a conclusion yet. The evidence is 
that this implementation seems to have a problem towards that end and 
the implementation was strongly driven by the desire to eliminate code 
duplication (more so than to structure it into logical aspects). I think 
that the attempt to eliminate duplicate code at all costs using traits 
may ultimately lead to this effect simply because if you try to squeeze 
all the entropy out of the system then the result will be a static 
structure.

Interfaces on the other hand, precisely *because* of the overhead they 
require tend to be more minimal, therefore more abstract and therefore 
more easily to maintain and (re)implement.

> Well that is a good technique.  I don't personally see Traits as hammer 
> or a silver bullet, but I do think they (at least have potential to) 
> fill a hole [1].

Are we talking about a hole in Java or in Squeak? Your example only 
applies to Java, not to Squeak (which has had #=, #==, #~~ and #~= in 
Object from its very first day). For that particular problem we didn't 
need traits. Now, I'm not saying there aren't places in which traits can 
be usefully applied - in fact I am *dying* to see a good use case. One 
where they actually help to make things simpler, structures clearer, 
more easy to understand.

> But since Traits can't have variables, I would expect them to be useful 
> in many of the same ways Haskell type classes are.  I could be wrong, 
> but I hope I'm not and I can't think of a technical reason Traits must 
> create fragility.

I need to read more about Haskell's type classes - I never looked too 
closely at them. Do they actually specify implementation or is it all 
type algebra (like in your example before)?

> But I also wonder if it is sort of a "hot button" issue.  I mean, there 
> are things to be frustrated/embarrassed about here (e.g. releasing 
> something into the image that appears to have no means of maintaining).

Of course it is frustrating. But what is worse is that while the paper 
examples all look fine I just haven't been able to find an improvement 
in understanding or design when I look at the (admittedly only) example 
of a real-world use. If that is the future with traits then it is a 
bleak future indeed. And of course it is quite possible that tools are 
missing, that early explorations go wrong but at least we should be 
honest enough to reflect critically on the artifact that was produced 
and see what is right and see what is wrong.

Cheers,
   - Andreas