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?
<br><br>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.
<br><br>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.<br><br>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?
<br><br>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".
<br><br>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. :)<br><br><div><span class="gmail_quote">On 8/3/07,
<b class="gmail_sendername">Andreas Raab</b> <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Damien Cassou wrote:<br>>> If you were to structure a stream library along these lines I think<br>>> you'll find that most of the uses for traits would go away because<br>>> besides the core protocol (which would appear in class Stream) there is
<br>>> actually very little duplication of responsibilities in there.<br>><br>> I do not agree. We will see what I can do and will discuss about this<br>> later if you want. But, yes it's possible to avoid duplication,
<br>> writing all the methods in the Stream class.<br><br>I understand that you can't possibly consider writing such a library<br>without using traits ;-) But to be blunt, since traits are a form of MI,<br>all the same methods of designing orthogonal systems apply that have for
<br>the last thirty years, and I'm pretty sure it's not only possible but<br>actually (just as always with SI vs. MI) easier to understand.<br><br>Cheers,<br> - Andreas<br><br></blockquote></div><br>