Re: String.ord

Daniel Berger wrote:
> 
> How would String#ord_at be a savings over String#[].ord?

One method lookup and invocation versus two lookups and two invocations 
plus the creation and garbage collection of a transient String object.

> I'm afraid I don't see such a method as being general enough to warrant 
> inclusion as part of the core class.

This is a backward compatibility issue.  It seems to me that there will 
be a general need for a simple way to achieve the the 1.8 behavior.
I think that warrants the addition of a method.

My original proposal, however was not to add a method, but to generalize 
String.ord itself so that it could accept an index and operate on 
Strings of any length.

While I'm posting on this again, let me add another response to Matz's 
last post.  Matz wrote:

> I just followed Python convention here.

There's a small difference here.  In Python ord() is a function, not a 
method of the String class.  I have an easier time accepting a global 
function that places a 1-character restriction on its string argument, 
than I do a String method that only functions on 1 character strings.
If one-character strings have different behavior than other strings, 
then shouldn't they be members of a different class?  If I can only call 
ord on some strings, shouldn't I be able to use respond_to? :ord on 
those strings?

I hope I'm not coming across as argumentative in this thread. I'm just 
having a hard time groking ord as it stands now. Perhaps this is due to 
ignorance: has anything been written (in English) explaining the whole 
scope of the text-processing changes in 1.9? I mean not just that 
characters are now single-character strings, but how multi-byte 
characters are going to be handled by the String class?

	David

> Regards,
> 
> Dan
> 
>