Streaming on OrderedCollection

Allen Wirfs-Brock Allen_Wirfs-Brock at Instantiations.com
Thu Sep 3 23:14:10 UTC 1998


At 02:50 PM 9/3/98 -0700, Travis Griggs wrote:
....
>Good idea. I looked at page 273 (section 5.9) where it shows that
WriteStream is the union of  <collectionStream>, <puttableStream>, and
<sequencedStream>. The description of <collectionStream> says:
>
>    "An object conforming to <collectionStream> has a
<sequencedReadableCollection> as its stream backing store." (5.9.3, pg 280)
>
>Now, if I flip back to page 156 (section 5.7), it shows that
OrderedCollection is among the union of many things,
<sequencedReadableCollection>.
>
>I'm not sure how interpret all of this legalise type reading, but it looks
like according to the ANSI spec that one should be able to WriteStream on
an OrderedCollection. Maybe Allen can help out with the interpretation?
>

Actually, what the standard says is that you can WriteStream "with" an
<OrderedCollection> rather than "on" an <OrderedCollection>. That is
<WriteStream factory> defines the selector #with: not the selector #on:

The standard specifies a consistent set of interaction between the initial
state of a "stream backing store" (which may be an <OrderedCollection>),
#nextPut: family selectors, #next: family selectors,  stream positioning
selectors, and the selector #contents. It does not specify how or if any of
these message changes the state of the <sequencedReadableCollection>
"string backing store" object that was the argument to the #with: method
that created a <WriteStream>. A <WritableStream> is allowed to modify the
state of its stream backing store but whether and how it is modified is
"implementation defined". This means that an implementation must publicly
document what happens.

Most of this complexity in the stream protocols arises from the fact that
among the widely used Smalltalks there is great variation in the
implemented semantics of WriteStream and ReadWriteStream when applied to
non-empty collections. Some implementations discard the existing content,
some operate upon a new collection, some append to the existing content.
The definition in the standard essentially allows for all these variations
while defining a consistent semantics that can be supported by all
implementations.  The basic rules for portability are: create ReadStreams
on non-empty collections using #with: and use #contents to get the results
of operations upon the stream.  Anything else will be implementation
dependent and non-portable.

Finally remember, the standard is all about protocols, not concrete classes
and implementations. Arrays, OrderedCollections, Strings,
SortedCollections, etc. are all <sequencedReadableCollections> and can be
used as an argument to #with: sent to the global object WriteStream.
However, nothing says that the <WriteStream> object returned from this
message must always be an instance of one particular class. An
implementation could, for example, have concrete classes named things like
ArrayWriteStream, OrderedCollectionWriteStream, SortedCollectionWriteStream
each of which knew how to deal with a specific type of stream backing store. 

Allen_Wirfs-Brock at Instantiations.com





More information about the Squeak-dev mailing list