Stream interfaces

[Thomas Burns]

"Dave Harris" <brangdon at cix.co.uk> wrote in message
> [...]
> I expect we need more delegation. The main thing is to
> separate out the formatting front-end, which needs a rich and probably
> varied API, from the data-sink back-end which can use a much smaller
> and more uniform API. Then we can do buffering etc by means of
> pluggable adaptors, and construct pipelines like:
>     XmlStream -> CompressionAdaptor -> SocketStream

You can get one implementation of this from the VisualWorks Freebies site at
http://smalltalk.iwarp.com.  The free package "Streams & Bytes" contains a
generic StreamWrapper class.  I got sick of creating my own streams, then
realizing that there wasn't a good place to hang them.

The StreamWrapper has been used in some of the other free packages.  For
example, the Zlib (zip-style compression, for those that don't know) package
subclasses StreamWrapper to do compression and decompression on the fly via
streams.  There is also a ProgressReadStream that, when used in conjunction
with the WidgetExtensions, can open a progress bar showing progress reading
through fixed-length streams (such as file streams or internal streams).

> This is roughly the approach of the Java library. As far as I know it
> works reasonably well.

Don't get me started.  :-)

This is what Java provides through the availability of the BufferedWriter
and BufferedOutputStream.  But in Java these (string-writing vs.
byte-writing) are 2 separate hierarchies.  On top of that Writer and
OutputStream are abstract classes, not interfaces.  So you must root from
one of these hierarchies, no matter how badly they fit with your
implementation.  In all, I would say that providing the Buffered* classes is
a good thing, but it's no great shakes and there are other significant
problems magnified by typing issues.  Give me Smalltalk any day.

t
--
Thomas Burns
thomas.a.burns at usa.net
VisualWorks Freebies are available at http://smalltalk.iwarp.com