[ANSI-Smalltalk] Smalltalk file streams

Richard O'Keefe ok at cs.otago.ac.nz
Mon Oct 20 23:29:09 BST 2008


On 20 Oct 2008, at 3:00 pm, Paolo Bonzini wrote:

>
>> 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.

Sorry, wrong answer.
It *would* be a programmer bug *if*
(1) there were a way to find out how big the file is.

>
>
>> 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
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>




More information about the ANSI-Smalltalk mailing list