Ron,

> >   I must have missed this, but what would be the suggested behavior of
> > #writeToFile: and #readFromFile:?  Can they deal with WideStrings?
> > 
> 
> I had not considered WideString, my concern is mostly for the reading and
> writing of human readable files.

  And, a WideString is of course a human readable string, and the
external file generated from it should be a human readable file.

  But...  It seems that you're not implying to use UTF-8 no matter
what platform you're on, but rather change the encoding based on the
platfrom, right?

> Collections should write to a file with
> the proper separators for the current platform inserted between items.  When
> reading a human readable file it should parse the string so that either each
> line for the platform becomes an item on a collection or you should get a
> string that is has a cr between lines replacing the source separators as
> necessary.  

  It sounds like #writeToFile: is a thin wrapper to
MultiByteFileStream.  It just sets up the flags of it, and then calls
the existing methods such as #nextLine, etc., right?

> My belief is that helper methods here will help to explain the different
> streams; how they are tied to individual platforms, and will help to lower
> the cost of entry for working with files.

  Not sure what you mean by "different streams".  What are they?
There is only one Stream (MultiByteFileStream) that deals with the
external files.  Its flags (and converter) can be set to deal with
different external formats.

  Yes, a few helper methods would be convenient.  I just want to know
what you think would be a reasonable behavior.

-- Yoshiki