[squeak-dev] EndOfStream - cruft?

Levente Uzonyi leves at elte.hu
Tue Jul 23 00:59:59 UTC 2013


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.

Signaling an Exception when a ReadStream is #atEnd should not really cause 
performance issues. It can only be a problem, when you are repeatedly 
reading from short streams. Xtreams also uses this technique.


Levente

>
> frank
>
> On 22 July 2013 17:09, Chris Muller <asqueaker at gmail.com> wrote:
>> What if a system needs to allow nil objects in a Stream of objects and
>> have it be treated as just another object in the stream rather than
>> the EOS marker?
>>
>> So, maybe ReadStream>>#next _should_ be signaling EndOfStream, so the
>> sender of #next can know the difference in that scenario.  Since the
>> defaultAction is ^nil, presumably we could simply change #next to do
>> that with no breakage...
>>
>> On Mon, Jul 22, 2013 at 9:02 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> EndOfStream has no references in the base image. It claims to be used
>>> by ReadStream >> #next, but that's not true.
>>>
>>> Time to die/deprecate?
>>>
>>> frank
>>>
>
>


More information about the Squeak-dev mailing list