[DUG] Unicode [redux]

[Jolyon Smith]

>> (for some reason people seem to prefer to come up with their own
>> ideas about what I think).
>
> Don't flatter yourself. I don't really care what you think at all ;-)

What can I say....

http://blogs.embarcadero.com/abauer/2009/10/08/38901

<shrug>  (I didn't mean you specifically)


> How would such a solution work with runtime packages? Two different
packages?

This was all discussed at length before the Unicode implemented was
delivered.  There is even less point going over it now that we're stuck with
what we have.

The problem is that what we're stuck with is a mess, so all we can do is
talk about the mess as a way of finding our way out of it (in the sense that
by talking about the mess we might one day understand the mess well enough
to be able to live with it).

i.e. a new user coming to Delphi 2009/2010 for the first time is going to
have a hard time understanding even the simplest things, such as why
ANSIUppercase() takes a UnicodeString parameter let alone treats it as
Unicode whilst Uppercase() also takes a UnicodeString yet treats it as
ASCII.

Why isn't there simply:

  Uppercase(ANSIString)
  Uppercase(UnicodeString)
  Uppercase(WideString)

?

And why is all this stuff scattered around SysUtils, and StrUtils and
Character ?


I remember that when I started out with Delphi I learned a great deal by
exploring the VCL source - it was one of the things that made Delphi so
accessible.

But I feel sorry for anyone following the VCL code down the ANSIUppercase()
rabbit-hole in Delphi 2010.

Not least they are going to be thoroughly confused by the presence of
{$IFNDEF UNICODE} directives (what? you mean I can UNdefine UNICODE...?  Um,
no, you can't) and FastCode licensed versions of routines that can't now
ever be called (hmm, I like the idea of "Fast" code... now how do I go about
using these "Fast" functions..?.  well, you can't do that either).

Not to mention the {$ifdef MACOSX} directives!

The VCL these days looks a real mess, especially in the string handling
areas which are going to be source of great interest for anyone dealing with
the new, more complicated strings in Delphi these days.  And OK it perhaps
was never a particularly shining example of how to "do Delphi" in some
areas, but it wasn't ever this confusing.

The help isn't much, uh, help either.  Older hands may be used to that these
day but again, new-comers to Delphi aren't going to be very well served by
the muddled mess that is the "String Types" topic.