Re: String.ord

I'm not a contributor, but I am a user of ruby, and there is a
possibility that no one seems to have mentioned. What about having
String.ord return an array of integers, with a one character string
returning a one element array?

So "test".ord => [116, 101, 115, 116]
"a".org => [97]

Under this scheme, referencing a particular number is no more
difficult then it is now, just instead of "test"[2].ord, you'd do
"test".ord[2]. The biggest disadvantage I can see is the requirement
for creating the array, which for big strings could get expensive.
However, if the user is worried about that they can just do
"test"[2].ord[0], which would be significantly less expensive (though
slightly more than the current scheme).

I agree that there shouldn't be methods that only work with certain
strings. That, I think, just causes confusion and goes against the
object-oriented principles of ruby.

On 2/7/07, Matt Pattison <[e-mail]> wrote:
> On 2/8/07, David Flanagan <[e-mail]> wrote:
> > Nikolai Weibull wrote:
> > > On 2/7/07, Sam Roberts <[e-mail]> wrote:
> > >
> > >> 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.
> > >
> > > May I beg for an /important/ algorithm?
> >
> > Geez!  What does it take to satisfy you guys!  :-)
> >
> > Seriously, though, I thought that my suggestion for an optional index
> > argument to ord was a modest and sensible one.  Actually, I thought I
> > was just pointing out an oversight and I'm surprised at the resistance
> > it has faced.  Given the richness of the core Ruby API, I assume that
> > decisions about adding methods are based on elegance, and that is
> > permitted or even desirable to have more than one way to do something.
>
> FWIW, I think ord_at or a similarly named method sounds like a good idea.
> It's simple, and it's a good future alternative to the Ruby 1.8 and earlier
> behaviour of String#[] (when given a Fixnum argument).
>
> <snip>
>
> > Anyway, I can see why encoding issues and multi-byte character issues
> > argue strongly for representing characters as a kind of String.  Has
> > anyone argued for creating a Character class that extends String?  This
> > would be a natural place to put methods like ord and digit? alpha?, etc.
> > Also, I tend to think that characters should be immutable (I'm not sure
> > why) and having a subclass would probably allow that.
>
> I think a Character class could be a good idea, as I felt slightly
> uncomfortable in the past indexing into a string and being returned a
> Fixnum, and whilst returning a String containing one character is an
> improvement, from a purely aesthetic perspective I would prefer to be
> returned a Character (derived from a String), and have methods
> designed to act on characters factored out into this Character class.
> However I am not a Unicode or Ruby internals or language API expert,
> so I don't have the same level of insight to add as others in this
> thread.
>
> Matt
>
>


-- 
Micah Wylde