Jason Johnson wrote:
> To be blunt back (but intending no disrespect of course, as I respect 
> your code and conversational contributions a great deal), aren't you 
> showing a bit of bias here?  I see that you have a great dislike for MI 
> and believe me, I share it with you.  However you do see Java interfaces 
> as a separate entity, no?

Yes. But the main reason is that Java interfaces a) implicitly encourage 
minimal interfaces (since you can't provide an implementation there is 
no reason to add anything but the minimal set of methods that need to be 
supported) and b) that they describe only the "what" (interface) not the 
"how" (implementation).

Contrast this with traits (or MI in general) where larger interfaces are 
implicitly encouraged (adding utility methods or "refactoring" the 
interface which ultimately leads to a *worse* interface which is much 
larger than it needs to be and that you can't get rid of since it's 
needed by the implementation) and the need to traverse a multitude of 
hierarchies to understand where some implementation comes from plus the 
need to disambiguate by renaming and you end up in a nice spaghetti bowl.

The ultimate problem with traits (MI) isn't state - it's that it drops 
the idea of encapsulation (objects staying individual entities) and 
simply merge the implementation into a common name space. That this 
isn't a great idea is known as far back as C's #include statement.

> To me this is what Traits are, not a method of MI.  And this is 
> something missing we see in every "OO-ish" system.  Ruby and Strongtalk 
> (at least) made "mixins" to deal with it.  Self went with something that 
> looks like full-blown MI, etc., etc.  What we seem to want in OO systems 
> is basically a formalization of the protocols.  Not just a textual 
> category I can put the methods in, something first class.  I can learn 
> about an object by looking at the "interfaces", "traits" or "type 
> classes" (which ever you prefer) it supports via runtime reflection.  I 
> know you can ask the classes what methods are in what categories but 
> that isn't a guarantee; the classifications are pure convention.

Indeed. Having interfaces to describe what is expected of a particular 
responsibility is a very, very good idea. Sharing the implementations 
via MI-like mechanisms is not. Note however, that for example mixins 
preserve the encapsulation of objects in much stronger ways than traits 
by not merging the name spaces but rather constructing a unified 
inheritance chain. From my POV this is advantageous to what traits do.

> In the case of Nile here, I have not personally seen the code and it may 
> indeed be overly complex.  But to get to a correct, intuitive stream 
> system how would you deal with the fact that some streams are, by nature 
> read-only and even write-only?  Surely not by a "isReadOnly" variable 
> switch?

Why not? I haven't seen very many streams which "by their nature" would 
be read-only or write-only. There are no such streams in Squeak for 
example; there are only those that have been made arbitrarily read-only 
(ReadStream) or that have attributes describing their readability state 
(FileStream). But even if there were, it is not clear to me that it is 
advantageous for a client to receive a MessageNotUnderstood instead of a 
ReadOnlyStream error. Since Squeak isn't statically typed, there is not 
much of an advantage here.

Cheers,
   - Andreas