Re: String.ord

Quoting [e-mail], on Wed, Feb 07, 2007 at 09:10:52AM +0900:
> Nikolai Weibull wrote:
> 
> >>But then you muse about a new type of Fixnum to represents characters!
> >
> >No, what I go on to say is that perhaps we need a new class for
> >representing the /codepoint/, not the character.
> 
> I think that these are the same thing.  And, if you're going to define a 
> class to represent a codepoint/character, then why not have String.[] 
> return it?

I found it strange at first that ruby didn't have a character class, and
that it just used strings of length 1, then I got used to it. It works
fine. I don't see any problem with String@ord just working just with
single character strings. But I don't think it would surprise anybody
if it did take an index, either.

But is it better? I've worked with binary a bunch, but I usually am
interested in much more than one byte at a time, and I usually use
String#unpack.  As has been pointed out, its not even easier to type,
the only difference seems to be a temporary string:

  "ab"[1].ord
  "ab".ord(1)

Is creating a temporary 1-byte String really that expensive? Some
benchmarks showing an algorithm that uses a long binary string as a data
structure performs much faster with String#ord(i) than String#[i].ord
would probably convince everybody.

Btw, isn't ruby 1.9 going to have character set information associated
with strings? Would #ord(idx) return the value of the byte at a
particular byte offset idx, or a codepoint at a character idx?

Sam