Stream interfaces

[Thomas Gagne]

Something has gone wrong only when it's gone wrong.

Dave Harris wrote:

> tgagne at ix.netcom.com (Thomas Gagne) wrote (abridged):
> >                 ExternalStream
> >                     BufferedExternalStream
> >                         ExternalReadStream
> >                             ExternalReadWriteStream
> >                         ExternalWriteStream
> >                 InternalStream
> >                     WriteStream
> >                         ReadWriteStream
>
> Do you agree this hierarchy is a bit duff? Notice how "Write" appears in
> 3 leaf classes: ExternalReadWriteStream, ExternalWriteStream,
> ReadWriteStream. These apparently share no implementation or interface.

My first thought was, "So what?"  Without studying the internals of the
classes to see what was or wasn't inherited it matters little what a class'
superclass is.  A program is only dependent on the classes' interfaces it
uses, not the super classes' interfaces.  It doesn't make sense to me to
critisize a hierarchy unless it has resulted in a faulty or unusable class.  I
haven't read any messages suggesting those throwing rocks at OO discovered
ExternalWriteStream was functionally deficient or misleadingly named.

>
> Notice also that in one place we get a trio of classes:
>
> >                         ExternalReadStream
> >                             ExternalReadWriteStream
> >                         ExternalWriteStream
>
> and in another we get a pair:
>
> >                     WriteStream
> >                         ReadWriteStream
>
> yet they would seem to be doing the same kind of thing. How do I get an
> internal stream which is readable but not writable?

Forgive my attempt at documentation.  Had I know someone would focus on the
hierarcy as closely as this I would have been a little more thorough (my
apologies to CinCom).

    InternalStream
        ReadStream

> If ReadWriteStream
> inherits from WriteStream, why doesn't ExternalReadWriteStream inherit
> from ExternalWriteStream?

I'm unclear why it matters.  Do you want an ExternalReadWriteStream?  Use it.
When you call a C function in a vendor-provided library (like an operating
system) do you analyze the code as closely or are you only thankful the
function exists so you didn't have to write it?

>
>
> Something has gone wrong here.

Your correct.  People are confusing inheritence and usefulness.  I don't have
enough spare cycles to worry about a class' inheritence unless I've discovered
missing functionality.  Since I haven't, I haven't.

Let's examine another one with a hierarchy I'm more familiar with (from the
opensource middleware isectd):

Object
    ExternalInterface
        IsdIO (low-level interface to isdio.so)
    IsdClient (high-level interface to isdio.so, more OOriented)
        IsdWorker (abstract - framework for writing a server)
            IsdEcho (a simple server that returns whatever it receives)
                IsdWorkerReplyStream (an abstract for workers that build their
replies on a stream)
                    IsdEat (a simple worker that collects all the message
fragments and returns stats to the client about them)
                    IsdSmalltalkWorker (send it Smalltalk code, it compiles
and executes it.  Very useful.  Very dangerous)
                    IsdXMLWorkerAbstract  (builds an XML Document from the
request, prints the reply XML Document back)
                        IsdGemWorker (an abstract worker for connecting to
Gemstone/S, adds convenience methods for transactions)
                            IsdEfiWorker (my current probject -- top secret)

>
>
>   Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
>       brangdon at cix.co.uk      |   And close your eyes with holy dread,
>                               |  For he on honey dew hath fed
>  http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

--
.tom