See also http://bugs.squeak.org/view.php?id=6755
For Andreas, the first problem was performance.
For me, there is another one: a Notification can get miss-interpreted at
the wrong level (see post below).
I later started SqueaXTream to steal Stream composition idea from Xtreams
and also have a versatile end of stream handling and let programmer choose
whether he wants returning nil, another special object or get an Exception
when a stream reaches its end.
See
http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/139338

Sure, Xtreams supersedes all that stuff, so my experiments staled.


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

>  Well, I dug around a bit more. Seems Andreas was concerned about
> performance, although I did not see an issue. A week later it was rolled
> back.
>
> Also in question was the correct superclass for EndOfStream. I just made
> the change in a 4.2 image and TestRunner is not happy with it being an
> Error. Make it an Exception and that problem goes away.
>
> Cheers,
> Bob
>
> 5/24/00     Re: RE: EndOfStream an Error???
>
> On Wed, 24 May 2000 01:32:44 -0700 "Raab, Andreas"
> <Andreas.Raab at disney.com> <Andreas.Raab at disney.com> wrote:
> >As it is right now, we're paying the
> >price of an error recovery for something that happens quite often. There
> are
> >many places where senders of #next rely returning nil quickly if at the
> end
> >of the collection. Such as in #next:into:startingAt:, #nextChunk,
> >#nextDelimited:, #peekFor: etc. With the changes we have a slowdown of
> >approx. 500 for a simple test case like
> >
> >    | s |
> >    s _ ReadStream on: Array new.
> >    [1 to: 100000 do:[:i| s next]] timeToRun.
> >
> >While the slowdown is okay for an error recovery it is most definitely not
> >okay for those users who do in fact rely on the opposite - which is a
> quick
> >return of nil for a past end read operation. And as it stands ALL those
> >users are affected by the modification.
>
> Andreas,
>
> Do you have an example that's a little more realistic? I was wondering
> what the effect would be on typical code, so I made a change to count the
> number of times that EndOfStream was actually signalled. Then I browsed
> around for a while and when I checked the number, it was still zero! So, I
> thought, filing in some code ought to do it. Nope - still zero. It wasn't
> until I evaluated "(ReadStream on: '1') nextChunk" that I actually got a
> hit. Hmm...
>
> Cheers,
> Bob
> ======================
> 5/24/00    Re: RE: EndOfStream an Error???
>
> On Wed, 24 May 2000 12:32:32 -0700 "Raab, Andreas"
> <Andreas.Raab at disney.com> <Andreas.Raab at disney.com> wrote:
> >What I do know, however, is that not too long ago we've integrated a
> change
> >set (I think from Bert) which modified quite some places to use the
> >#next/#isNil test instead of #atEnd. Which leads me to the assumption that
> >there ought to be places in which a quick return might be really critical.
>
> I think there is an important distinction here. If you have code like:
>
> [s atEnd] whileFalse: [el _ s next. el whatEver]
>
> then you will be sending #atEnd for each element in the stream and sending
> #next one less time. By changing that to
>
> [(el _ s next) isNil] whileFalse: [el whatEver]
>
> you are essentially substituting #isNil for #atEnd for every element. That
> can add up to substantial savings. The change to EndOfStream changes only
> the performance of the *last* #next while all the others (assuming there
> are elements in the stream) remain as fast as ever. There will clearly be
> some performance penalty, but the magnitude will depend on the number of
> elements processed before end of stream. If the typical case involves empty
> streams, then the cost will be quite high. If the typical stream processed
> as above has tens or hundreds (or more) of elements, then the cost of
> EndOfStream will be a much smaller fraction of the total processing time.
>
> I think, as has already been suggested, it might be wise to back off this
> change until we resolve whether Error or Exception is a better place for it
> (I lean toward Exception, Notification or perhaps
> ErrorsForWhichTheDefaultActionIsUsuallyAcceptable rather than Error). Once
> that is decided, we can see if there are any noticeable performance hits,
> especially once EndOfStream is added to the other places where it can be
> detected (StandardFileStream>>next, e.g.).
>
> Cheers,
> Bob
>
> ==============================================
>
>
>
>  On 7/22/13 2:31 PM, Chris Muller wrote:
>
> Interesting, I wonder what the consequences were..
>
> On Mon, Jul 22, 2013 at 11:22 AM, Bob Arning <arning315 at comcast.net> <arning315 at comcast.net> wrote:
>
>  For the historically-obsessed,
>
> Change Set:        069EOS-hh (really2192EOS-hh)
> Date:            18 May 2000
> Author:            Helge Horch
> Requires:        Squeak 2.8a
>
> Modifies ReadStream>>next to signal an Error (EndOfStream) on attempts to
> read
> at or beyond the end of the stream.  Thanks to Bob Arning (who is silently
> credited
> in the stamps <g>), existing applications relying on seeing nils should not
> be
> affected.
>
> Change Set:        102ReadStreamUndo-sma (really 2272ReadStreamUndo-sma)
> Date:            1 June 2000
> Author:            Stefan Matthias Aust
>
> Undo #2192. The consequences of raising an exception for EOF during
> ReadStream>>next should be worked out in 2.9a but not for 2.8.
>
>
> and, AFAIK, that was the end of that.
>
> Cheers,
> Bob
>
> On 7/22/13 12:09 PM, Chris Muller 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/20130722/fd98072d/attachment-0001.htm