On Aug 12, 2009, at 02:02, Brian Candler wrote:
> Eric Hodel wrote:
>> On Aug 7, 2009, at 00:52, Brian Candler wrote:
>>> Eric Hodel wrote:
>>>> I'm too lazy to dig this out of the archives, but there are some
>>>> encodings that don't have a 1:1 mapping to Unicode thus the round-
>>>> trip
>>>> through UTF-8 (etc.) will destroy them.
>>>
>>> Indeed, although we're both having a hard time thinking of an actual
>>> example. It seems that dealing with such things is not an everyday
>>> requirement for most people.
>>
>> This seems to be similar to the reasoning behind two-digit years.
>
> I don't understand what you're getting at.

"dealing with [non 1:1 conversion round trips] is not an everyday  
requirement for most people" is roughly equivalent to "four-digit  
years is not an everyday requirement for most people" (or was, back  
when people were using two-digit years)

> You're saying you want to avoid external->Unicode->external encoding
> transcodings.

I was stating that this is a design goal of ruby's encoding features.   
(And likely causes much of the pain you feel in this area.)

> But these are rarely problematic (I've still not seen an
> example), and in those rare cases you could just handle the external
> encoding as binary data.

Agreed.  Furthermore, most of the time software is likely to only work  
within a single encoding.

> Remember also that for stateful encodings, you're forced to  
> transcode anyway - even ruby 1.9 won't handle snippets of  
> ISO_2022_JP in isolation, for example.


Software written without this in mind will probably be used this way  
regardless of the original authors' intent (and will break), much like  
two-digit-year software did when four-digit years became necessary.

PS: I think you can provide valuable input on how to make ruby's API  
for encodings more robust and easier to use, but you seem to hate it  
so much that you can't be bothered to raise issues in a way that will  
get them fixed.