2009/11/27 Eliot Miranda eliot.miranda@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@gmail.com wrote:
On Fri, Nov 27, 2009 at 2:24 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2009/11/27 Colin Putney cputney@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