On 8/4/07, <b class="gmail_sendername">Andreas Raab</b> <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes. But the main reason is that Java interfaces a) implicitly encourage<br>minimal interfaces (since you can't provide an implementation there is<br>no reason to add anything but the minimal set of methods that need to be
<br>supported) and b) that they describe only the "what" (interface) not the<br>"how" (implementation).</blockquote><div><br><br>Well that's one way for a language beat people into doing things the way it wants. :) But from what I have seen the inability to specify a default implementation causes people to either have the same code duplicated (which Java programmers don't mind because Java is a language one writes and uses tools to write), or hierarchies that make no sense, since they were only made to avoid duplication of code.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Contrast this with traits (or MI in general) where larger interfaces are<br>implicitly encouraged (adding utility methods or "refactoring" the
<br>interface which ultimately leads to a *worse* interface which is much<br>larger than it needs to be and that you can't get rid of since it's<br>needed by the implementation) and the need to traverse a multitude of
<br>hierarchies to understand where some implementation comes from plus the<br>need to disambiguate by renaming and you end up in a nice spaghetti bowl.</blockquote><div><br><br>Well, this is certainly true of MI, but it isn't true for type classes and I, therefore, don't believe it has to be this way for traits. It is a valid concern though and I have seen things already that look like what I would consider mis-uses of the technology (and for anyone who will ask, no I don't remember what, just methods too big for a trait IMO).
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The ultimate problem with traits (MI) isn't state - it's that it drops
<br>the idea of encapsulation (objects staying individual entities) and<br>simply merge the implementation into a common name space. That this<br>isn't a great idea is known as far back as C's #include statement.</blockquote>
<div><br><br>If used that way then sure, of course you're right. But IMO traits are supposed to be a signal that says "I implement this protocol" in a first class manner. The fact that they allow you to define a default implementation is good to avoid code duplication but it should not be used to have a form of MI.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Indeed. Having interfaces to describe what is expected of a particular<br>
responsibility is a very, very good idea. Sharing the implementations<br>via MI-like mechanisms is not. Note however, that for example mixins<br>preserve the encapsulation of objects in much stronger ways than traits<br>by not merging the name spaces but rather constructing a unified
<br>inheritance chain. From my POV this is advantageous to what traits do.</blockquote><div><br><br>Hrm, I guess I need to go dig deeper into exactly how mixins work because I don't understand what you mean here. I looked a little at Strongtalk mixins and they seemed to be a function that applied to a class to inject existing methods into it somehow. I mentally wrote it down as being the same thing as a Haskell type class and Squeak traits.
<br> <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Why not? I haven't seen very many streams which "by their nature" would
<br>be read-only or write-only. There are no such streams in Squeak for<br>example; there are only those that have been made arbitrarily read-only<br>(ReadStream) or that have attributes describing their readability state
<br>(FileStream). But even if there were, it is not clear to me that it is<br>advantageous for a client to receive a MessageNotUnderstood instead of a<br>ReadOnlyStream error. Since Squeak isn't statically typed, there is not
<br>much of an advantage here.<br><br>Cheers,<br> - Andreas</blockquote><div><br><br>I was thinking of the user level, not the programmer level. For example, write-only streams would be /dev/null, one could see a UDP connection as a write-only as well as TCP in some cases (
e.g. the data socket in an FTP transaction). Read-only are even more common (e.g. files on read-only media, files you have read-only access to, etc.).<br><br>I was also thinking of it as negative to have to have certain methods protected by a "isWritable/Readable" type flag in an OO language, but you bring up a good point about typing. On the other hand, in practice what the user will see is something like "ReadOnlyStream does not understand: writeData:", right? That would be just as informative to me as "ExternalStream is readonly", since once you see the DNU pop up you would say "oh yea, of course it doesn't understand writing", no?
<br></div></div>