From: Charles O Nutter Date: 2006-06-15T11:23:38+09:00 Subject: Re: Unicode roadmap? ------=_Part_3383_12569723.1150338215531 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I believe that Julik's way of solving the unicode problem (String#u providing access to a unicode helper) is very attractive. I have two questions related, for Julik and the rest of the peanut gallery: 1. How does performance look with the unicode string add-on versus native strings (or as compared to icu4r, which is C-based)? 2. Is this the ideal way to support unicode strings in ruby? And I explain the second as follows....if we could assume 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 indexed elements of that 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? Is it simply libraries or core APIs that explicitly need *byte* counts? (Of course this is somewhat rhetorical; we do this currently with JRuby since Java's strings are UTF-16...we just don't have any uniform way to provide access to UTF-16 character strings, and we normalize everything to UTF-8 for Ruby's sake...but what if we didn't normalize and adjusted string functions to compensate?) On 6/14/06, Julian 'Julik' Tarkhanov wrote: > > As an example of something that is ridiculously backwards to do in > Ruby now is this (I spent some time refactoring this today): > http://dev.rubyonrails.org/browser/trunk/actionpack/lib/action_view/ > helpers/text_helper.rb#L44 > -- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com ------=_Part_3383_12569723.1150338215531--