If yours is better there shouldn't be much of a reason to keep the bad one, 
right? I'd just suggest that pharo does not depend on zinc classes but the 
encoder moves to pharo with a different name.

Norbert

> Am 30.04.2015 um 11:42 schrieb Sven Van Caekenberghe <[email protected]>:
> 
> 
>> On 30 Apr 2015, at 11:13, Guillermo Polito <[email protected]> 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
> 
> 
> 


Reply via email to