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

On Jun 15, 2006, at 12:30 AM, Austin Ziegler wrote:

> On 6/14/06, Mark Volkmann <r.mark.volkmann@gmail.com> wrote:
>> On 6/14/06, Austin Ziegler <halostatue@gmail.com> wrote:
>> > ... in my code I
>> > have used #length and #size interchangeably depending on which  
>> reads
>> > better in context.
>> I've never been a fan of the Ruby practice of having many names for
>> the same thing, but I'm willing to be convinced. Can you give me an
>> example of two string variables where getting the number of  
>> characters
>> reads better with "length" for one and "size" for the other?
>
> It's all code context. "name.length" reads better than "name.size" and
> "box.size" reads better than "box.length". Remember, in Ruby you
> *don't* know whether you're dealing with a String, Array, or Hash (or
> something else) when you're dealing with simple method calls.
> Similarly, I will use #map most of the time, but sometimes I'll use
> #collect.

Are you sure that "box" happened to be a variable for a string  
object? ;)

> In any case, these are well-established names and having them differ
> would be problematic. That *said*, I'll have to fix stuff in Ruby 2
> for PDF::Writer because I'm currently doing byte counting, not
> character counting.

My proposed change won't disturb anyone's existing codes unless you  
set $KCODE to be 'u' as well in that code. If you did set $KCODE to  
'u' in your previous projects, you don't have to apply this hack  
(which hasn't been implemented yet) to that project.

Matz has said several times that he will maximize the breakage moving  
to Ruby 2.0. If Matz is going to make these changes for Ruby 2.0, (as  
implied in Guy Decoux's posting) I think I will just follow along. My  
goal is to provide Ruby 2.0 forward compatible unicode support until  
the move is complete.


Dae San Hwang
daesan@gmail.com