From: Dae San Hwang <daesan@...>
Date: 2006-06-15T23:26:33+09:00
Subject: Re: A plan for another unicode string hack

--Apple-Mail-3-275688409
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Jun 15, 2006, at 9:03 PM, Julian 'Julik' Tarkhanov wrote:

> To the original poster - frankly I don't see the point of doing  
> this all over again. If you want to have unicode handling
> that way just grab it from my plugin. It's just that when you have  
> to work with external libraries they
> will not cooperate. I was using this String class in the wild for a  
> few months, so trust me. It's not simply
> because I "felt" like removing this functionality - it simply Broke  
> Alot Of Stuff In A Variety Of Subtle Ways.

Hi Julian. I have tried your plugin in the past and I appreciate your  
efforts on better unicode supports on Ruby. The reason I'm proposing  
a different hack is because people have been advising against the use  
of your unicode hack due to its incompatibilities with other  
libraries. So, I figured that we need a way of differentiating  
between plain old string and new hacked string with explicit  
encoding. (I got the hint and inspiration from http:// 
redhanded.hobix.com/inspect/futurismUnicodeInRuby.html) That way it  
can be backward compatible with existing libraries and yet be forward  
compatible with Ruby 2.0.

> Separation of "size" and "length" is sensless because they are  
> aliases in Ruby. It would be sensible
> to have "byte_" prefixed methods for byte access, just as I had in  
> my hacks plugin a while ago. It worked too.

My proposal for differentiating method names between 'size' and  
'length' has risen from my personal itch. I have always appreciated  
Ruby's intuitiveness and I think 'size' is an intuitively better name  
for byte size of a string and 'length' is better suited to give the  
length of a string. I might be being compulsive here but I think this  
kind of attention to details have earned the title of the programer  
friendly language to Ruby. Guy Decoux have pointed out that Matz has  
considered this change himself once and obviously many people on the  
forum welcome this change. (Equal number of people voted against it  
as well, 7:7 at the moment.)

Some people have pointed out that 'size' doesn't give byte size in  
other classes like array or hash but what matters here is the  
context. 'size' meaning byte size in the context of string object is  
pretty damn intuitive in my opinion. Ruby have used 'size' and  
'length' to mean the same thing in the past but I believe that  
decision was consciously made by Matz thinking that people would  
prefer to use 'size' when they are using the string as byte buffer  
and use 'length' when they are using the string as character string.  
(I wouldn't know what Matz was thinking when he designed the String  
API but that's my guess.) Regardless of my feelings on this issue, I  
will just follow what Matz decides for Ruby 2.0 String API as one of  
my goals here is to provide forward compatibilities as much as possible.

Thanks to everyone who replied. I appreciate all your comments and  
will post back when I get something working.

Best regards,

Daesan


Dae San Hwang
daesan@gmail.com


--Apple-Mail-3-275688409--