Hi all!

On 11/02/2010 07:54 PM, Andreas Raab wrote:
> On 11/2/2010 8:44 AM, Göran Krampe wrote:
>>> One of the reasons to make it subclass is to reuse behavior inherited
>>> from Stream.
>>> But if subclass needs to override 90%+ of inherited methods, then it
>>> makes not much sense.
>>> I didn't measured how much methods need to be overridden by
>>> SocketStream, but i suspect it is the case, since sockets are quite
>>> special.
>>
>> Yes, that is my guess too. And yes, just going by the "is a" test may
>> create brittle classes which break when changes are made because they
>> really are too different.
>
> Huh? What is the conceptual difference between a ReadWriteStream and a
> SocketStream? The main difference is that the former is an internal
> stream, the latter an external stream. But in terms of behavior they are
> more similar than different as expressed by having to a large number of
> methods with the same name and behavior (i.e., Stream methods).

Fair enough, I don't have them in front of me so you may be correct. 
Hmmm, ok, took a quick look and hey, ReadWriteStream is a 
PositionableStream for starters which btw holds instance variable 
"collection" etc. How does all that relate to SocketStream?

> As a
> consequence, there is good reason to be wanting to define some
> additional methods in terms of these protocols, in my case I was
> actually looking at promoting some methods up to class Stream to have
> them accessible to all kinds of streams, including SocketStream. I can
> of course keep duplicating these methods but it seems completely
> pointless given that they're all streams and as a result should share a
> common heritage.

Again, if it looks like SocketStream can be fit into the Stream 
hierarchy without too much "oddities" then I am not saying I am against 
it. My guess is still though that a SocketStream is "a bit different" in 
nature.

> As for brittleness, in my experience brittleness is generally the result
> of accessing state directly (i.e., the superclass accesses state
> directly and that can break an invariant introduced by a subclass). But
> as it happens, Stream is stateless, so I really don't see where any
> brittleness would be introduced. I'd be curious about where you think
> brittleness would come into play and why.

Well, I think it *generally* is fairly easy to find brittleness in 
Smalltalk inheritance chains - for example if looking closer at 
Collections etc. It is quite easy to accidentally inherit methods that 
will not work for a subclass.

regards, Göran