[ANSI-Smalltalk] Smalltalk file streams

Paolo Bonzini bonzini at gnu.org
Fri Oct 17 07:00:20 BST 2008


> Again, an exceedingly unhelpful response.

To explain my short answer of PEBKAC: the keyboard and the chair are the
programmer's, if that's not clear.  The standard *can* provide methods
that sometimes make sense and sometimes don't.  If they don't, and the
result could be infinite request of memory or an infinite loop, it's a
problem of the user.

Certainly, it would be *insane* to require that #contents detects device
files where it cannot terminate.  And it would be even *impossible* to
detect in advance whether #contents on a socket would terminate, but yet
it would be useful to provide #contents on a socket.  It's a problem
that *programmers* sitting between a keyboard and a chair have to solve,
not whoever writes the standard.

> there is no "THE ... way" that the Array new: call
> would fail;

But I'd expect #contents on a 500 GB data file to fail *that same* way.

>> The erratum here is that #contents belongs in <gettableStream> and
>> <WriteStream>, not in <collectionStream> and <FileStream>.  I sent
>> another email on the subject.
> 
> Except that for smallish files, #contents is quite useful.

Indeed.  <FileStream> *is* a <gettableStream> isn't it?

Paolo



More information about the ANSI-Smalltalk mailing list