From: Mike Calder Date: 2004-05-05T01:11:21+09:00 Subject: Re: Strange behaviour of Strings in Range As an outsider, and as an application programmer, if the language has to resort to special add-on libraries or different method names to handle different character data types, forget it. A string is a string is a string. As an application programmer I want to be able to use substring, split, character by positional index, and all the other standard string methods and not have to worry about what kind of string data I am handling. I'm prepared to pass a parameter to stream handlers telling them what type of encoding to use between external streams and internal representations if I have to - or even between different internal representations if that's the sort of thing that is a particular programmer's bag. I could even live with parameters like that on the standard string methods if I had to. But the original code that I code and test to work with &mylanguageofchoice; MUST work with ANY other language, without change. All other language users must have to do to get my program to work in their language is to translate fixed strings (and perhaps change GUI layouts because of sizings). This is absolutely basic and should be in the Ruby core. I thought this kind of thing was why we have OO. How you do it, I don't care. I don't care what the internal representation is; that's an implementation detail, the sort of thing that OO should be hiding from me anyway. All I know is I'm handling a string, and I want to do string manipulations. I don't care is it's Unicode or ASCII, Kanji or Kanuck. Sorry, if I can't do that in Ruby, it's broken and, I'm afraid, unusable. On Tuesday 04 May 2004 15:28, Martin Elzen wrote: > Hi everyone. > > I've looked up the references Robert Klemme found by searching for I18N on > the Ruby-talk archives, I also did the same myself, and also read up some > more about Unicode. One of the requirements someone wrote up was that > multinationalizing Ruby may *not* make it any harder to work with Japanese > character set than it already was, and that having to convert existing > Japanese files to Unicode was simply not an option. > > Given all that (to my surprise) I've reached the conclusion that Unicode > does *not* seem like the way to go (at least, not as part of the Ruby > language proper - a good Unicode library does seem like a must). It looks > like the most flexible option is to permit the creator of a string object > to specify it's character width, and give the string object the capability > of reporting it's own character width. Basically that's what the C++ > standardisation group did - IIRC any sequence of 'character-like' objects > that can be copied without causing calls to non default constructors or > destructors (and especially not calls to non default copy constructors) is, > technically and in principle, a standards compliant C++ string, regardless > of the size in character width of those 'character-like' objects. Of > course, the C++ standard also defines IO stream and stringstream libraries > that can be used by both std::basic_string and > std::basic_string objects... (though unfortunately not all library > implementations have caught up yet). A more doable alternative to > requiring such character-width independent libraries might be the use of > special reader/writer classes to handle conversions to and from specific > byte-widths (and perhaps also endian-ness conversions) where necessary > (which is what Java does, I gather). > > Sincerely, > Martin > > _________________________________________________________________ > MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl -- Clear skies! Mike Calder. If you have received this email in error, please notify me by replying. This email and any attached files are confidential and intended solely for the addressee. If you are not the intended recipient, then you must not: Disclose the contents to anyone other than the intended addressee; Copy or forward this email or any attachment; Take any action in reliance on anything in the email or attachments.