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?

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.

Now, for sure people can abuse traits just as people abuse MI and even SI
(look at half the Java hierarchies out there).  In my first experience with
Haskell type classes I abused them horribly to create effectively a class
hierarchy.  But misuse can indicate a faulty abstraction (e.g. MI IMO), or
that we simply need better training with it.

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?

Your concept of "Fixed Size", "Variable/Infinite Size" and "Transforming" is
solid.  But I think such a setup would be benefited with traits to make the
first class distinction between "read", "write" or "read-write".

NOTE:  Having said all this, my statements only stand for "state-less"
traits.  IMO "stateful" traits are exactly MI and therefor I am not a fan.
:)

On 8/3/07, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> Damien Cassou wrote:
> >> If you were to structure a stream library along these lines I think
> >> you'll find that most of the uses for traits would go away because
> >> besides the core protocol (which would appear in class Stream) there is
> >> actually very little duplication of responsibilities in there.
> >
> > I do not agree. We will see what I can do and will discuss about this
> > later if you want. But, yes it's possible to avoid duplication,
> > writing all the methods in the Stream class.
>
> I understand that you can't possibly consider writing such a library
> without using traits ;-) But to be blunt, since traits are a form of MI,
> all the same methods of designing orthogonal systems apply that have for
> the last thirty years, and I'm pretty sure it's not only possible but
> actually (just as always with SI vs. MI) easier to understand.
>
> Cheers,
>    - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070804/d3313284/attachment.htm