On 4 Feb 2017, at 19:09, stepharong <stepharong@free.fr> wrote:
2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven@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.
OK.
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.
Sven
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?
Stef
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. Sven