EndOfStream an Error???

Helge Horch Helge.Horch at munich.netsurf.de
Wed May 24 13:19:20 UTC 2000


At 23:23 23.05.2000 -0700, Andreas Raab wrote:
>Just wondering: Who came up with the idea that EndOfStream is an error?!

I'm the one to be blamed here.

At 01:32 24.05.2000 -0700, Andreas Raab replied to Paul McDonough:
> > It seems like EndOfStream could just as well be implemented as a
> > Notification ... ?
>
>Perhaps yes. Perhaps no. It seems to me that the entire issue is going a bit
>deeper. EndOfStream *could* really mean an Error - that is representing
>something like an attempt to read beyond the elements stored in the stream.
>But then, we really need to fix up all the users of #next which rely on a
>quick nil return for past-end reads.

I am (slowly, however) working through this- Bob Arning already provided a 
couple of pointers into #next's senders list,

PositionableStream>>upToEnd
Base64MIMEConverter>>nextValue
DataStream>>next

and, as you kindly pointed out,

StandardFileStream>>peekFor: (cf. PositionableStream>>peekFor:)
PositionableStream>>nextDelimited:
PositionableStream>>nextChunk
PositionableStream>>next:into:startingAt:
InflateStream>>next:into:startingAt:

plus

String>>unescapePercents
CrLfStream>>upTo:
FlashFileStream>>nextByteForBits
FreeCellBoard>>resetStacks

and probably quite a couple of places more.  GIFReadWriter>>nextByte I'll 
have to at least look at, too.

BTW, I'm using the results of

"this takes a while..."
| testers senders both |
testers _ #(isNil notNil ifNil: ifNotNil:
         ifNil:ifNotNil: ifNotNil:ifNil:
         == = ~= ~~)
     inject: OrderedCollection new
     into: [:accum :each | accum addAll: (Smalltalk allCallsOn: each); 
yourself].
testers _ testers asSet.
senders _ Smalltalk allCallsOn: #next.
both _ (senders select: [:any | testers includes: any]) asSortedCollection.
MessageSet openMessageList: both
     name: 'next and nil (', both size printString, ')'
     autoSelect: both first
"---"

but this only reduces the list to 199 candidate methods.  I'm pretty much 
tied up for the upcoming weekend, so progress is slow.

>So, from my point of view we have two options: a) We can rely on a quick
>return nil from #next. That means no EndOfStream, which would require a bit
>more effort when porting stuff from other ST80 dialects.

We might push this change to 2.9a, until the senders of #next are 
fixed.  We could simply revert ReadStream>>next to its previous version for 
now.  Opinions, QC?

>b) We define a
>past-end read operation as an error. That means leaving EndOfStream as an
>error and fix up those clients that do implicitly handle EndOfStream by
>testing for nil. Both are valid options but b) will change a lot of
>fundamental code and require a coordinated effort to fix up all the senders
>of #next.

Too true.

To my dismay, this cs had a more widespread effect than I had hoped.  It 
may just not be ready for prime time without the sender fixes.  So, I can 
live with reverting for now, but I still think it'll make a worthwhile 
addition.  Once it's ready.

My apologies for causing overtime,
Helge





More information about the Squeak-dev mailing list