2009/11/27 Eliot Miranda <eliot.miranda at gmail.com>:
> An approach I like is to add an endOfStreamValue inst var to Stream and
> answer its value when at end.  This way nil does not have to be the
> endOfStreamValue, for example -1 might be much more convenient for a binary
> stream, and streams can answer nil without confusing their clients.  atEnd
> can be implemented as
>     atEnd
>         ^self peek = self endOfStreamValue
> You can arrange to make streams raise an end-of-stream exception instead of
> the endOfStreamValue by using some convention on the contents of
> endOfStreamValue, such as if it is == to the stream itself (although I note
> that in the Teleplace image the exception EndOfStrean is defined bit not
> used).
>
> Of course, stream primitives get in the way of adding inst vars to stream
> classes ;)
> IMO this is a much more useful scheme than making nil the only endOfStream
> value.
>

Last time I proposed to have an inst var endOfStreamAction was here
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009536.html
.
Abusing nil value -> nil, I could even let this inst var
un-initialized and be backward compatible
(initializing with a ValueHolder on nil would do as well)

Nicolas

> On Fri, Nov 27, 2009 at 2:33 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>>
>>
>> On Fri, Nov 27, 2009 at 2:24 PM, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>> 2009/11/27 Colin Putney <cputney at wiresong.ca>:
>>> >
>>> > On 27-Nov-09, at 8:03 AM, David T. Lewis wrote:
>>> >
>>> >> I implemented IOHandle for this, see
>>> >> http://wiki.squeak.org/squeak/996.
>>> >> I have not maintained it since about 2003, but the idea is
>>> >> straightforward.
>>> >
>>> > Yes. I looked into IOHandle when implementing Filesystem, but decided
>>> > to go
>>> > with a new (simpler, but limited) implementation that would let me
>>> > explore
>>> > the requirements for the stream architecture I had in mind.
>>> >
>>> >> My purpose at that time was to :
>>> >>
>>> >>  * Separate the representation of external IO channels from the
>>> >> represention
>>> >>   of streams and communication protocols.
>>> >>  * Provide a uniform representation of IO channels similar to the unix
>>> >> notion
>>> >>   of treating everything as a 'file'.
>>> >>  * Simplify future refactoring of Socket and FileStream.
>>> >>  * Provide a place for handling asynchronous IO events. Refer to the
>>> >> aio
>>> >>   handling in the unix VM. Files, Sockets, and AsyncFiles could
>>> >> (should)
>>> >> use
>>> >>   a common IO event handling mechanism (aio event signaling a
>>> >> Smalltalk
>>> >> Semaphore).
>>> >
>>> > Indeed. Filesystem comes at this from the other direction, but I think
>>> > we
>>> > want to end up in the same place. For now I've done TSTTCPW, which is
>>> > use
>>> > the primitives from the FilePlugin. But eventually I want to improve
>>> > the
>>> > plumbing. You've done some important work here - perhaps Filesystem can
>>> > use
>>> > AioPlugin at some point.
>>> >
>>> > Colin
>>> >
>>> >
>>>
>>> I wonder why level 3 stdio was used (FILE * fopen, fclose ...) rather
>>> than level 2 (int fid, open, close, ...) in file plugin... Better
>>> portability ?
>>
>> level 2 isn't really a level, its a section of the unix manual pages.
>>  Section 2 is the system calls (which really define what unix is).  Section
>> 3 is libraries.  So only the stdio library in section 3 is portable across C
>> implementations.  So yes, you're right, the use of the C library's stdio
>> facilities was chosen for portability.
>>>
>>> Nicolas
>>>
>>
>
>
>
>
>