SocketStream not a Stream?

Hi -

I (accidentally) noticed that SocketStream isn't a subclass of Stream.
Is there any reason why this should remain true? It strikes me as odd as
Stream has very few requirements (basically #next, #nextPut:, and
#atEnd) which are trivially fulfilled by SocketStream. Anyone seeing a
reason not to change this?

Cheers,
   - Andreas

On Mon, 1 Nov 2010, Andreas Raab wrote:

> Hi -
>
> I (accidentally) noticed that SocketStream isn't a subclass of Stream. Is
> there any reason why this should remain true? It strikes me as odd as Stream
> has very few requirements (basically #next, #nextPut:, and #atEnd) which are
> trivially fulfilled by SocketStream. Anyone seeing a reason not to change
> this?

It should also implement #contents, but that's trivial to do.


Levente

>
> Cheers,
>  - Andreas
>
>

Hi!

On 11/02/2010 04:55 AM, Andreas Raab wrote:
Well, when I wrote the current version I think I decided against it
since I did not want any "inherited bugs" so to speak. If a clean and
useful inheritance is possible, then sure. The other reason it might be
unwise is that it does both input and output - but of course that does
not mean a useful inheritance is possible anyway.

regards, Göran

Message: 16
Date: Tue, 02 Nov 2010 08:06:11 +0100
From: G?ran Krampe <[hidden email]>
Subject: Re: [squeak-dev] SocketStream not a Stream?
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


> Well, when I wrote the current version I think I decided against it
> since I did not want any "inherited bugs" so to speak. If a clean and
> useful inheritance is possible, then sure. The other reason it might be
> unwise is that it does both input and output - but of course that does
> not mean a useful inheritance is possible anyway.

> regards, Göran

I don't know anything about SocketStream so my comments may be
way off base.

If SocketStream does both output and input then it sounds like it should
have an instance variable (a Stream) for input and an instance variable
(another Stream) for output.  On the other hand if what you mean by
doing input and output is that is reads and writes to the same place then
it sounds like SocketStream should not only be a subclass of Stream but
a subclass of ReadWriteStream.

Like I said, I don't know anything about SocketStream.

Regards,

Ralph Boland

What makes object to be a stream? Belonging to Stream hierarchy? Apparently not.
Its a behavior and protocol.

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.

--
Best regards,
Igor Stasenko AKA sig.

Hi!

On 11/02/2010 04:41 PM, Igor Stasenko wrote:
> What makes object to be a stream? Belonging to Stream hierarchy? Apparently not.
> Its a behavior and protocol.

Exactly.

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

regards, Göran

Hi!

On 11/02/2010 03:48 PM, Ralph Boland wrote:
> I don't know anything about SocketStream so my comments may be
> way off base.
>
> If SocketStream does both output and input then it sounds like it should
> have an instance variable (a Stream) for input and an instance variable
> (another Stream) for output.

That was indeed the original design of the old SocketStream btw. The
current implementation is instead written more directly using buffers to
get better performance.

> On the other hand if what you mean by
> doing input and output is that is reads and writes to the same place then
> it sounds like SocketStream should not only be a subclass of Stream but
> a subclass of ReadWriteStream.

I don't think so, a ReadWriteStream typically reads and writes the
*same* buffer. A SocketStream wraps a Socket which talks to a service
that decides what to answer etc.

regards, Göran

On 11/2/2010 8:44 AM, Göran Krampe wrote:
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

Hi all!

On 11/02/2010 07:54 PM, Andreas Raab wrote:
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