Re: Ruby 1.8 vs 1.9

Robert Klemme wrote in post #963807:
>> But that basically is my point. In order to make your program
>> comprehensible, you have to add extra incantations so that strings are
>> tagged as UTF-8 everywhere (e.g. when opening files).
>>
>> However this in turn adds *nothing* to your program or its logic, apart
>> from preventing Ruby from raising exceptions.
>
> Checking input and ensuring that data reaches the program in proper
> ways is generally good practice for robust software.

But that's not what Ruby does!.

If you do
  s1 = File.open("foo","r:UTF-8").gets
it does *not* check that the data is UTF-8. It just adds a tag saying 
that it is.

Then later, when you get s2 from somewhere else, and have a line like s3 
= s1 + s2, it *might* raise an exception if the encodings are different. 
Or it might not, depending on the actual content of the strings at that 
time.

Say s2 is a string read from a template. It may work just fine, as long 
as s2 contains only ASCII characters. But later, when you decide to 
translate the program and add some non-ASCII characters into the 
template, it may blow up.

If it blew up on the invalid data, I'd accept that. If it blew up 
whenever two strings of different encodings encounter, I'd accept that. 
But to have your program work through sheer chance, only to blow up some 
time later when it encounters a different input stream - no, that sucks.

In that case, I would much rather the program didn't crash, but at least 
carried on working (even in the garbage-in-garbage-out sense).

> Brian, it seems you want to avoid the complex matter of i18n - by
> ignoring it.  But if you work in a situation where multiple encodings
> are mixed you will be forced to deal with it - sooner or later.

But you're never going to want to combine two strings of different 
encodings without transcoding them to a common encoding, as that 
wouldn't make sense.

So either:

1. Your program deals with the same encoding from input through to 
output, in which case there's nothing to do

2. You transcode at the edges into and out of your desired common 
encoding

Neither approach requires each individual string to carry its encoding 
along with it.

-- 
Posted via http://www.ruby-forum.com/.