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