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<char> and
> std::basic_string<wchar_t> 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.