FileStream concreteStream MultiByteFileStream
Yoshiki Ohshima
yoshiki at squeakland.org
Thu Mar 17 07:26:46 UTC 2005
Stan,
> At present, for my own purposes, CrLfFilestream has two advantages over this
> solution. First, with CrLfFilestream, when I edit the file in the
> filelist, the line terminators inserted are consistent with the other
> terminators in the file. Second, CrLfFilestream makes the file appear
> immediately with line breaks where expected, while the encoded text
> solution requires some clicking in the bottom pane before the file is
> formatted.
>
> Of course, I understand that CrLfFilestream has one very important
> disadvantage; it cannot display multibyte characters.
The other advantage is that MultiByteFileStream subsumes the
CrLfFileStream's feature. From programmers' point of view, having
redundant classes that do similar things is bad, right?
> I think the cause of MultiByteFileStream not writing at all is the line
> brevityState == #fullFile ifTrue:
>
> If that is changed to, for example,
> (#(#fullFile #'iso-8859-2') includes: brevityState) ifTrue:
> then MultiByteFileStreams can be written from the FileList.
Sorry, I didn't quite understand here.
> I think the cause of MultiByteFileStreams writing with CR instead of
> platform line terminators is that detectLineEndConvention returns LF
> for CrLfFileStream and returns nil for MultiByteFileStream.
>
> CrLfFileStream new detectLineEndConvention (print it yields #lf)
> MultiByteFileStream new detectLineEndConvention (print it yields #nil)
There is some semantics change. If you would like a
MultiByteFileStream to detect the platform line end convention, you
need to call #wantsLineEndConversion: first. For example,
(MultiByteFileStream new wantsLineEndConversion: true) detectLineEndConvention
returns a symbol.
-- Yoshiki
More information about the Squeak-dev
mailing list
|