On 6/14/06,
Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> wrote:
On 15-jun-2006, at 3:50, Charles O Nutter wrote:
> I agree it's a very attractive solution. I have two questions
> related (perhaps you are out there to answer, Julik):
>
> 1. How does performance look with the unicode string add-on versus
> native strings?
> 2. Is this the ideal way to support unicode strings in ruby?
>
> And I explain the second as follows....if we could assume that
> switching from treating a string as an array of bytes to a list of
> characters of arbitrary width, and have all existing string
> operations work correctly treating those characters as string,
> would that be a better ideal? Where are the breaking points in such
> a design? What's to stop the underlying implementation from
> actually using a UTF-16 character, passing UTF-8 to libraries and
> IO streams but still allowing you to access everything as UTF-16 or
> your encoding of choice? (Of course this is somewhat rhetorical; we
> do this currently with JRuby since Java's scrints are UTF-16...we
> just don't have any way to provide access to UTF-16 characters, and
> we normalize everything to UTF-8 for Ruby's sake...but what if we
> didn't normalize and adjusted string functions to compensate?)
This is more appropriate for ruby-talk
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
