EndOfStream an Error???

Raab, Andreas Andreas.Raab at disney.com
Wed May 24 08:32:44 UTC 2000


> 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. 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.

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. 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.

Personally, I have no strong preference towards any of the options. But it's
not acceptable for me that we're running a full error recovery cycle for
those cases where a quick return is expected, basically combining the worst
parts of both approaches.

  - Andreas





More information about the Squeak-dev mailing list