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