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.

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091127/dd35e849/attachment.htm