On 8/4/07, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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).



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.

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.



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).


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.



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.


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.



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.


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



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.).

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070805/a7b2e6d5/attachment.htm