> On 30 Apr 2015, at 11:13, Guillermo Polito <guillermopol...@gmail.com> wrote: > > Hi! > > I'm struggling with the TextConverter's API in Pharo :). > > I wanted to test the converters in Pharo, and I found the method > #convertFromSystemString: that should (from its name) convert a Pharo String > into an encoded version of it. > > (UTF8TextConverter default convertFromSystemString: 'á'). > > Funny thing, it does not do that. It does the opposite: it tries to convert > an encoded string to a pharo string. And so it fails. Of course, its > symmetrical version does what I want and behaves as the ZnUTF8Encoder :) > > (UTF8TextConverter default convertToSystemString: 'á') asByteArray > "#[195 161]" > > ZnUTF8Encoder new encodeString: 'á' "#[195 161]" > > Question: > - does the convertTo/From methods makes sense to you or It's just me that > sees them inverted? > - does it make sense to have the two versions of converters? Zn and the > TextConverters do the same in my opinion (or maybe I'm confused :) ) > > Guille
I am biased, but the Zn converters are better. Why ? Because they work between String <-> Bytes as a text encoder/decoder should. They also have a number of extra features (counting the number of encoded bytes, being able to move backwards on input, being able to be very strict), are faster and have a clearer implementation. Furthermore, they are more correct and implement more encodings. There is also good documentation http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ ZnCharacter[Read|Write]Stream are also very instructive, compare them to MultiByteStream. Should we throw the other one out ? Probably. But it is the same problems as with Xtreams: the API is different and adding a compatibility layer would defeat the purpose. So I don't know. Sven
