On 9-Sep-06, at 9:26 AM, Andreas Raab wrote:

> tim Rowledge wrote:
>> Well as I recall it, you were employed in the thick of the team of  
>> people with control over the image for several years around that  
>> time. What were the reasons for not adopting such a filestream  
>> back then?
>
> Because I was the only non-Mac user in an otherwise 100% Mac  
> environment ;-)
Interesting - so the problems faced by all the unix and windows users  
weren't thought important. Tut-tut.

> And for some of these things I just couldn't convince the gang that  
> it's worthwhile (otherwise we would have also switched the yellow/ 
> blue button definitions
Never! The *only* machines that had a sensible mouse as standard  
along with a reasonable and compatible button usage were RISC OS ones.

Well, for what it's worth I'm strongly in favour of filestreams  
having the capability of handling line-end translation. It worked for  
a long time in Smalltalk-80v2 IIRC and still does in VW. I don't care  
much how the implementation is done but it really ought to be the  
case that as user of the filestream can use 'FileStream' and whatever  
needs to be done is hidden. We could have it wrapping a  
CRLFTranslatingFileStream or a NoTranslatingFileStream or a  
MultibyteFileStream, or using state variable or whatever, but you  
simply shouldn't have to know. Tell your filestream '#binary' if you  
want raw bytes, #text for translated text, whatever.

Just look at FileStream. I mean, really. The class comment is a  
disgrace. And then 'StandardFileStream' - standard how? And why are  
assorted font readers implemented as subclasses of CrLfFileStream?   
And HTMLFileStream?  Euch.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: IAM: Increase Amperage Above Maximum