[ANSI-Smalltalk] Smalltalk file streams

[Paolo Bonzini]

> The standard needs to say something about this.
> If there's a section of the ANSI standard that talks about
> it, I've been unable to find it.
> 
> Note that running out of memory is an implementation limit.

Sure -- but running out of memory because you try to slurp the entire
contents of a file in memory without first checking its size, is a
programmer bug.

> Anyone designing a new language would almost surely have
> designated a standard exception to be raised when #perform:
> gets an arity clash.  It seems bizarre that ANSI Smalltalk
> has one of the most elaborate exception handling schemes
> around and makes so little use of it.  But that's another
> issue.

Agreed.

>> Certainly, it would be *insane* to require that #contents detects device
>> files where it cannot terminate.
> 
> You keep on talking about cases where #contents cannot
> TERMINATE.  But I was and remain talking mainly about
> cases where #contents cannot START.

I see now one difference between what you expected and what I expected:
for some historical reason, on GNU Smalltalk #contents will always
return only the *future* contents of the file; only ReadStream and
ReadWriteStream include the past contents of the file.  Probably it was
done to minimize the differences between the handling of pipes and
regular files, I don't remember.

>  - if you only have write access to an external resource,
>    you can *never* perform #contents on it.  So it doesn't
>    *EVER* make sense to have #contents in the <writeFileStream>
>    protocol.

Of course.

> However, <gettableStreams> in general cannot support #contents
> either.  Do we agree that #contents belongs in <ReadStream>,
> <WriteStream>, and <fileReadStream>?

I answered in another message earlier today.

Paolo