[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