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
