[squeak-dev] EndOfStream - cruft?
Bob Arning
arning315 at comcast.net
Tue Jul 23 01:33:50 UTC 2013
Given that there might be a performance issue in some (rare) cases, but
especially because of the potential for the wrong handler seeing the
exception, another approach might be more acceptable. Some possibilities:
=======================
next
<primitive: 65>
position >= readLimit
ifTrue: [^eos] "a new instance variable the user can leave
nil or set to preferred marker"
ifFalse: [^collection at: (position := position + 1)]
=======================
nextIfNone: aBlock
<primitive: 65>
position >= readLimit
ifTrue: [^aBlock value]
ifFalse: [^collection at: (position := position + 1)]
=======================
nextOrEOS: endOfStreamMarker
<primitive: 65>
position >= readLimit
ifTrue: [^endOfStreamMarker]
ifFalse: [^collection at: (position := position + 1)]
=======================
nextOrSelf
<primitive: 65>
position >= readLimit
ifTrue: [^self] "if the stream is known not to contain
itself, then self could be the marker"
ifFalse: [^collection at: (position := position + 1)]
=======================
Cheers,
Bob
On 7/22/13 8:59 PM, 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.
>
> 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
>>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130722/38f1e6c0/attachment.htm
More information about the Squeak-dev
mailing list
|