On 18 Jul 2017, at 16:10, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Tue, Jul 18, 2017 at 3:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
These are all aliases [ see: https://en.wikipedia.org/wiki/ISO/IEC_8859-1 ].
So you could add it, yes
But why use TextConverter at all ?
I used this because this is what I found while browsing for code. When I did this code the CI was down I could not access to EnterprisePharo.
You could keep on using the alternative (more modern, cleaner) ZnCharacterEncoder hierarchy.
Just open your streams binary and wrap a ZnCharacterReadStream around them with the encoding of your choice.
fileReference binaryReadStreamDo: [ :in | (ZnCharacterReadStream on: in encoding: #latin1) ... ]
I just tried to use this but it broke my code. For example, ZnCharacterReadStream does not understand #position: while the ReadStream hierarchy understand it.
In general, the stream API is much, much too wide, IMHO. Not all streams (hence the word stream) can see all their content all the time (think of network or encrypted streams, most work with a sliding buffer, but in general the idea of a stream is to *not* hold everything in memory at the same time). If you look at it that way, many operations stop making sense. Positioning is one of them. Even in Java not every stream is positionable, and even if they are positionable, the positioning can fail because you go too far (back). In all parsing code that I write I try to only use 1 item look ahead (a single item buffer), which means you can #peek 1 item, that's it. I know that we have parsing code that was written with other assumptions. Such code is not stream based, IMHO. The solution (or rather workaround) is easy: read everything #upToEnd and turn it into a good old ReadStream again. You will give the use infinite positioning over all of the content, at the cost of more memory usage.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France