------art_71683_13863043.1151418526280
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

It won't matter much either way to JRuby, since Java's going to internalize
all strings as UTF-16 anyway. Those encodings that can't be represented in
unicode simply won't work, since that's just a platform limitation we'll
probably live with. There's always the option of building our own
uber-string based on what matz creates (porting to Java wouldn't be
impossible, or perhaps even difficult) but we'll cross that bridge when we
come to it.

I'm just trying to play both sides of the fence here since there seems to be
a number of people opposed to or doubtful of the m17n uberstring. As a Ruby
platform implementer of a sort I'd like to make sure those concerns are
considered.

On 6/27/06, Pit Capitain <pit / capitain.de> wrote:
>
> Charles O Nutter schrieb:
> > (...)
> > Hey, the uber-string m17n impl might be the most amazing, remarkable
> > thing ever to come along. It just seems based on a lot of anecdotal
> > evidence that this approach is very complex and very dangerous, and
> > arguably has never been done right yet. matz and company are amazing
> > hackers, but is it a good risk to take? Is it worth it for 10% of
> > Ruby users or less?
> > (...)
>
> Charles, could it be that "the uber-string m17n implementation" would
> make your life as JRuby implementer a lot harder? ;->
>
> Regards,
> Pit
>
>


-- 
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com

------art_71683_13863043.1151418526280--