Well, my concern had been allayed by Levente -- I use the nil check
approach so often I had forgotten about #atEnd.  So if I want nil's in
a Stream I can use atEnd.  In light of this, I myself am indifferent
whether we signal a EndOfStream or not.

On Tue, Jul 23, 2013 at 4:58 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 23 July 2013 03:08, David T. Lewis <lewis at mail.msen.com> wrote:
>> On Tue, Jul 23, 2013 at 02:59:59AM +0200, Levente Uzonyi wrote:
>>> On Mon, 22 Jul 2013, Frank Shearar wrote:
>>>
>>> >I'm half-tempted to say "in that case the user should use Xtreams".
>>> >Because the weird behaviours around #next and #atEnd were pretty much
>>> >the main drivers behind it.
>>> >
>>> >Do you use EndOfStream like this (to allow nil objects in a Stream of
>>> >objects)?
>>>
>>> Your question is misleading. nil can be in any stream, but #next will also
>>> return nil, when the stream is #atEnd. If you know that your stream
>>> doesn't have nils in it, then using #next is safe (and fast), otherwise
>>> you should not rely on #next's return value to decide if it was a valid
>>> read or not. That's what #atEnd is for.
>>
>> A bit off topic, but possibly worth mentioning - for OSProcess, I found
>> it useful to make an additional distinction between #atEnd (nothing more
>> available right now) versus #atEndOfFile (nothing more available on the
>> stream ever because the source is closed and we have read all available
>> elements from the stream).
>>
>> Thus you can read #upToEnd to obtain all of the data currently available in
>> a stream (e.g. a stream on the reader end of an OS pipe), and you can read
>> #upToEndOfFile to wait for all data on the stream until the writer of that
>> stream is known to be done writing to it.
>
> Since it sounds like people might want to use EndOfStream and alter
> ReadStream, I've just pushed EndOfStream into the Collection-Streams
> package.
>
> This morning's rash of commits empties Exceptions completely. All the
> Exceptions now live close(r) to the classes that make use of them.
>
> frank
>
>> Dave
>>
>>
>