Hi stephane

Then it is once again a discussion about Exception.
If exception is implemented and you don't want it, then you catch it and 
resume with appropriate value. Easy.
If exception is not implemented and you want one, then you have to 
protect each next with either a pre atEnd test, or post ifNil: test. 
Easy too. (Heavy, too I would say to my personnal taste).

Just a question of style...

Also think of Damien's argument (Array new: 10) readStream would answer 
nil to next. Not easy to discriminate atEnd with a single ifNil: test.

We should not be hurted by either solution, except when porting an 
application to a different dialect not implementing same rules. If this 
is what you mean by hurted, then this is an argument to adopt most 
common behaviour, that is not the squeak one. Unless I misunderstood 
something?

Nicolas


stephane ducasse a écrit :
> Bill
> 
> I cannot reply exactly but I can tell you that some of the choices of VW 
> to trhow an error
> when at the end of a stream deep down in the library hurt us (roel and 
> me long time ago and this is really bad).
> 
> Now I will let damien take into account your feedback
> 
> Stef
> On 14 mai 07, at 23:28, Bill Schwab wrote:
> 
>> Damien,
>>
>> I had to read that a few times, but I think I follow.  *If* I do, then
>> the answer is that for your gettable stream, you would not consider
>> hitting the end to be an error.  An analog in Dolphin would be
>>
>>    'hello' readStream nextWord
>>
>> which evaluates to 'hello'.  The stream is left at its end, and a
>> subsequent #nextWord evauates to nil (which I find questionable).
>>
>> Don't take my word for it.  Try asking #next: to read off the end of a
>> stream in Dolphin and VW - you will find the both environments complain
>> about it, and I submit they are correct to do so.  #nextAvailable: will
>> silently truncate if it hits the end of a stream, which is sometimes the
>> correct behavior.  IMHO, the problem at present is that Squeak assumes
>> all is well in situations that call for an error; the result is that
>> additional error checks are required, and history teaches us that they
>> will not always be included.
>>
>> Bill
>>
>>
>> Damien Cassou wrote:
>> I thought about it however there is a problem. When you have a
>> gettable stream, you don't always know how much elements remain in the
>> stream. You are then obliged to read all elements before you know if
>> there was enough or not.
>>
>> This is a problem because once read, the elements may not be available
>> anymore. So, if the method signal an error, all elements that have
>> been read are lost.
>>
>>
>>
>>
>> Wilhelm K. Schwab, Ph.D.
>> University of Florida
>> Department of Anesthesiology
>> PO Box 100254
>> Gainesville, FL 32610-0254
>>
>> Email: bschwab at anest.ufl.edu
>> Tel: (352) 846-1285
>> FAX: (352) 392-7029
>>
>>
>>
> 
> 
>