[squeak-dev] EndOfStream - cruft?

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Jul 23 17:23:10 UTC 2013


Bob,
been there, done that in SqueaXTream: but with a slightly different inst
var:

next

    <primitive: 65>
    position >= readLimit
        ifTrue: [^endOfStreamAction value]    "a new instance variable the
user can leave nil or set to preferred marker"
        ifFalse: [^collection at: (position := position + 1)]

It works for a block, nil, etc ...


2013/7/23 Bob Arning <arning315 at comcast.net>

>  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><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><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/20130723/cc426a34/attachment.htm


More information about the Squeak-dev mailing list