[Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)
Sven Van Caekenberghe
sven at stfx.eu
Sat Feb 4 14:07:55 EST 2017
> On 4 Feb 2017, at 19:09, stepharong <stepharong at free.fr> wrote:
>>> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven at stfx.eu>:
>>> Hi Nicolai,
>>> The FileSystem API is a bit inconsistent, yes.
>>> This is how you can use it:
>>> (FileLocator temp / 'foo.txt') writeStreamDo: [ :out |
>>> out binary.
>>> (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ].
>>> (FileLocator temp / 'foo.txt') readStreamDo: [ :in |
>>> in binary.
>>> ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
>>> (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in |
>>> (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ].
>>> There is no #binaryWriteStreamDo:
>>> The API around File is more correct, IMHO.
>>> Does this help ?
>>> Yes, thanks for the fast response.
>>> What exactly is your question ?
>>> I am looking at the issues with FileList, there are some parts that don't work anymore (see FileList>>#contents, it calls some unimplemted methods), and it uses TextConverter and somoe parts of the older File api.
>>> It looks like most other (newer) parts are using ZnCharacterReadstream for encoding, but I couldn't find a way to use it together with FileReferences (most parts of the FileList already operate with the newer FileSystem API.
>> From my standpoint and understanding, I would always use binary streams with explicit Zn converters, this combination is much easier to understand and better implemented with more features.
>> If you encounter any problem or have any questions, I will gladly try to help you.
> I really think that we should clean and improve on this side.
> What would be a roadmap?
> - Improve filesystem API to call Zn
> - Deprecated other users? (what are they?)
> - what would be the next steps?
Guilermo's new File class with its simple binary streams can be perfectly combined (stacked) with Zn character encoding streams. A first step would be to make FileSystem return/produce those stacked streams.
I even believe there is a prototype integrating this.
I believe you are one (the ?) author of Nile, so you know very well how complex stream users are - that is the challenge. Authors of parsers or protocols that depend on streams should write to minimal API's, only using what they really need.
More information about the Pharo-dev