[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