Smalltalk: Requiem or Resurgence? Push for business application
Ron at USMedRec.com
Thu May 25 00:26:17 UTC 2006
> From: Yoshiki Ohshima
> Sent: Wednesday, May 24, 2006 6:49 PM
> > > I must have missed this, but what would be the suggested behavior of
> > > #writeToFile: and #readFromFile:? Can they deal with WideStrings?
> > >
> > Ron wrote:
> > I had not considered WideString, my concern is mostly for the reading
> > 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?
Yes and please forgive me for not having a better understanding of
WideString before responding. I saw 32Bit characters, I thought of binary,
math, cryptography (like 32bitRegister). International characters had not
occurred to me. I'm sorry.
What I would like to see is a way to read and write files with one simple
method that works for all platforms.
I don't know enough about how different platforms handle these extended
character sets. If there is a file format or platform that supports files
stored in this extended character format and if it is possible to detect
this file type, then it would make sense to convert to a WideString or a
collection of WideStrings when reading a file of this type. It would also
make sense to automatically write a file of this type, again if this type
exists, when writing out a file from a collection of WideStrings, or a
If these files types are not detectable or supportable then yes it would
make sense to always use UTF-8. In any case the goal is to have one method
that reads and writes available on String and on Collection which works for
> > Collections should write to a file with
> > the proper separators for the current platform inserted between items.
> > reading a human readable file it should parse the string so that either
> > line for the platform becomes an item on a collection or you should get
> > 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
> > the cost of entry for working with files.
> Not sure what you mean by "different streams". What are they?
Originally I tried to do this:
dir := FileDirectory default.
(fileStream := dir fileNamed: 'test.txt') ascii.
fileStream nextPutAll: 'a\b' withCRs.
fileStream flush; close.
Which used MultiByteFileStream but it wasn't configured correctly so instead
dir := FileDirectory default.
fileStream := CrLfFileStream fileNamed: (dir fullNameFor: 'test.txt').
[ fileStream nextPutAll: 'a\b' withCRs.
fileStream flush; close ] ensure: [ fileStream close ]
If this method already works for all platforms then that's the
implementation of the helper method.
> 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
I appreciate your interest.
More information about the Squeak-dev