Smalltalk: Requiem or Resurgence? Push for business application

Yoshiki Ohshima yoshiki at
Thu May 25 01:20:19 UTC 2006


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

  No need to say sorry!  (But I might point out that this was one of
the reason I wrote back in April why it wouldn't work well.  When the
interoperability with the platform and other applications are

> What I would like to see is a way to read and write files with one simple
> method that works for all platforms.  

  Me, too.  But I kind of doubt it.

> 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
> WideString.
> 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
> all platforms.

  The definition of "work" is somewhat ambiguous.  For example, on the
Japanese Windows, Shift-JIS "work" better than UTF-8 in a sense, and
other way around in other sense (and ISO 2022 works for particular
applications like emails.)  And on the Chinese Windows, GB 2312 (or
such) is "better", in a sense.

  (We don't actually think such alien languages^^; ISO-8859-* and
UTF-8 will give the case.)

  Again, going to a platform neutral approach has its advantages, and
"by default", I think it is reasonable.  (UTF-8 and CR.)

> >   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
> I needed: 
> 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.

  Well, there is a lot to say about this code^^;

  First, #close implies #flush, so you don't need it.  And, #ensure:
means that the ensure block is executed no matter what, so you don't
have to put #close in the receiver block.

  (I guess you just wanted to illustrate the idea, but just a
sidenote...  Using #ensure: just to close the file is quite debatable,
especially if it covers just a part of method.  In the above code, the
file open error is notified to the user (or calling method).  However,
if the writing fails for some reason such as disk-full, it siliently
closes the file and pretends the requested operation was successful.
And, think about an hypothetical case where opening file succeeds but
the assignment to the 'fileStream' variable fails...)

  All in all, for writing:

| dir fileStream |
dir := FileDirectory default.
fileStream := dir fileNamed: 'test.txt'.
fileStream wantsLineEndConversion: true.
fileStream nextPutAll: 'a\b' withCRs.
fileStream close.

and then for reading the file:

| dir fileStream result |
dir := FileDirectory default.
fileStream := dir readOnlyFileNamed: 'test.txt'.
fileStream wantsLineEndConversion: true.
result := WriteStream on: Array new.
[(line := fileStream nextLine) notNil] whileTrue: [
    result nextPut: line
fileStream close.
^ result contents.

seems to do one way we might want it to do.  If these are helper
methods to be used in various applications, the error handling should
be done by the callers, as the different applications want to do
different things upon an error.

-- Yoshiki

More information about the Squeak-dev mailing list