Hi,

In message "Re: Subrange of String subclass => invalid object"
    on 02/01/30, Dave Thomas <Dave / PragmaticProgrammer.com> writes:

|I know absolutely nothing about m17n, so forgive me if this is
|naive. In Unicode, I believe that it is possible for two 'characters'
|to be equal even if their bit patterns are different: there are
|different ways of representing the ways that the characters are
|constructed. Might that be an argument in favor of a character class,
|so that
|
|   str.char_at(i)  #=> aChar
|
|and aChar retains sufficient information from the String to allow
|
|   aChar == otherChar
|
|to be evaluated correctly?

Yes.  But there's other normalization requirement for other encoding
than Unicode.  I'm not against about Char class, but I don't think
there can be consensus.

|I know you live with this nightmare daily, and you've thought this
|through a lot more than I have, but as the encodings get more complex,
|doesn't the need for Char increase. After all, there are both sins of
|commission and sins of omission, and both lead us to the same gate :)

The point is if I provide any Char class, arbitrary half of the world
will complain.  As long as the least functionality can be accomplished
by code point numbers (see [ruby-talk:32744]), I think it's OK to
leave Char class to users.

							matz.