Op Fri, 26 Sep 2008, schreef Marco van de Voort:
In our previous episode, Dani?l Mantione said:
That's highly dependant on what you application does! If your
application primarily parses text files, it's relevant. :-)
Shortstrings & ansistrings won't go away. You'll still be able to code
fast text file parsers. Note that in such cases your application won't
process unicode, taking the numbers example again: As soon as your
application accepts arabic numbers everywhere western numbers are allowed,
you want the parsing to happen in UTF-16.
Accepting both Arabic and Westernized Arabic numerals would possibly break a
lot of code anyway, since to string and back wouldn't be reversible.
It has never been reversible. Think about val('$100',v);
actually already isn't with Delphi I know, due to hex and padding handling,
but this would be a magnitude worse)
You want to handle it transparently. Otherwise you get a mess like
that people need all kind of ugly case constructs, having to call a
different "val" routine depending on the language the program is shown in.
That way you never will get good multi-lingual support.
For many people Unicode is just "let's go UTF-8". It's far more than that
and 100% supporting Unicode is even next to impossible.
You can't seperate val from str, and what would str(100,s) do?
It could accept an extra optional parameter for the desired script or
something like that.
Daniël
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
