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.

Dave