> On 4 Apr 2018, at 11:38, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> 
> wrote:
> 
> Hi Sven,
> See also discussion at 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/232

Thanks Nicolas, I had already seen parts of it.

Now, I still want image level changes to be based on clear semantic definitions 
of the abstract stream API, we're not just talking about file or unix streams, 
the general Smalltalk concept.

For reading, they are IMHO,

#next
#readInto:startingAt:count:
#peek
#atEnd
#upToEnd (can be derived but still the semantics are important in relation to 
#atEnd)

For writing, we have

#nextPut:
#next:putAll:startingAt: 
#flush

For both, we have

#atEnd
#close
#closed (new)

So, I know, #next returning nil exists, but is it universally/officially 
defined as such ? Where is that documented ?

Positioning, sizing are not universal, IMHO, but should be clearly defined as 
well.

> 2018-04-04 11:32 GMT+02:00 Sven Van Caekenberghe <s...@stfx.eu>:
> Somehow, somewhere there was a change to the implementation of the primitive 
> called by some streams' #atEnd.
> 
> IIRC, someone said it is implemented as 'remaining size being zero' and some 
> virtual unix files like /dev/random are zero sized.
> 
> Now, all kinds of changes are being done image size to work around this.
> 
> I am a strong believer in simple, real (i.e. infinite) streams, but I am not 
> sure we are doing the right thing here.
> 
> Point is, I am not sure #next returning nil is official and universal.
> 
> Consider the comments:
> 
> Stream>>#next
>   "Answer the next object accessible by the receiver."
> 
> ReadStream>>#next
>   "Primitive. Answer the next object in the Stream represented by the
>   receiver. Fail if the collection of this stream is not an Array or a String.
>   Fail if the stream is positioned at its end, or if the position is out of
>   bounds in the collection. Optional. See Object documentation
>   whatIsAPrimitive."
> 
> Note how there is no talk about returning nil !
> 
> I think we should discuss about this first.
> 
> Was the low level change really correct and the right thing to do ?
> 
> Note also that a Guille introduced something new, #closed which is related to 
> the difference between having no more elements (maybe right now, like an open 
> network stream) and never ever being able to produce more data.
> 
> Sven
> 
> 
> 
> 


Reply via email to