[squeak-dev] Re: SocketStream not a Stream?
Andreas Raab
andreas.raab at gmx.de
Tue Nov 2 18:54:47 UTC 2010
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). 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.
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.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|