Re: Re[2]: Pre-information on Unicode in Delphi 2008

In article <30357573.20071129092425@xxxxxxxxx>, Kryvich says...

OK. In old applications String = AnsiString: replace String -->
AnsiString

By "old" you of course mean "all existing". I'm sure it's not as
appealing when it's put that way.


Char -- > AnsiChar and they will work in Delphi 2008
pretty well.

Yep, and will not compile if the new VCL is utterly Unicode.

var
s: AnsiString;
begin
s := Edit1.Text; // incompatible types

So "all existing" applications would break and simply making application
vars explicitly "AnsiString" won't help if those applications reference
other "String" variables (now incompatible UTF16) whose declarations
cannot be so simply changed.

I suppose we could accept just a warning, so instead of compile failure
just 100's or 1000's of warnings.

Nice.



In new applications we can use AnsiString, Utf16String (by default),
PChar, ShortString, Utf32String, Utf8String, WideString.

You can do that with the extended-RTTI implementation. This is not a
capability unique to a non-extended RTTI approach.


We don't need an universal String type

Of course we don't, and I'm not even suggesting that we HAVE a universal
string type. You are the one thinking that a string could be UTF8 one
minute and ANSI the next.

This is NOT what string encoding RTTI would be for, any more than RTTI
enables a published Integer property to suddenly be transformed into a
Byte.


use AnsiString when we need ANSI string, Utf16String when we need
UTF16 string etc.

You mean, exactly as an extended RTTI approach would allow. Extended
RTTI ADDITIONALLY would allow existing applications to migrate to
Unicode far more easily.


Delphi compiler will help us to check all string and
character type conversions at compile time, not runtime.

Right. Thereby breaking existing applications, unless you are going to
suggest that the compiler introduce automatic conversions, which would
sort of undermine your concern over data loss arising from such things,
no?

NOTE: RTTI means that type information is available at runtime. It does
NOT mean that the same type information is NOT available at COMPILE
time.


If a programmer really need convert integer to word, he has to write:

w := word(i); // It's OK, I care about this

That's not a conversion, it's a typecast - not the same thing at all.


Requirement of an ANSI string will decrease. Look: all modern OS,
databases, APIs, Internet services, and competitive IDEs use Unicode
strings by default.

Nonesense. Sorry but this is. It may be true for OS's, it certainly is
NOT true for databases, API's or internet services. Notoriously so in
the latter case.

Of those things you identify, databases may now provide comprehensive
Unicode SUPPORT, but whether that is default or not is irrelevant - what
is USED is what matters.

And I noticed that you left "applications" off of your list.

By no means all applications use Unicode, nor will there EVER be a day
when ALL applications NEED Unicode.


So that universal String type you offer for Delphi
simply will be not needed.

It may not be needed in the future, but I can see it being incredibly
useful in GETTING to that future.


--
JS
TWorld.Create.Free;
.

Relevant Pages

  • Re: How to display German Umlauts correctly on Mac and Unix
    ... > larger due to translation tables). ... If you have to custom compile build tools to get a feature, ... And with the Unicode translation steps. ... "are written using the Unicode character set". ...
    (comp.lang.java.gui)
  • Re: Multicast Socket for Win CE 4.2 / Pocket PC 2003
    ... API and multicast works, in general, on a variety of devices that I've built ... I can't speak directly for Pocket PC, ... The Unicode thing has *nothing* to do with incompatibility and Microsoft ... it does not even compile. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: What Id Like to See in Delphi
    ... informations given out by CodeGear staff members. ... My applications contain lots of low level stuff, ... I have nothing against Unicode and Unicode strings. ...
    (borland.public.delphi.non-technical)
  • Re: String Manipulations
    ... >> Unicode although after taking your advice it worked as I originally ... >> within the same scope of the CString example that wont compile either. ... >> Perhaps my project environment needs to be adjusted a bit? ... >> sample code shouldn't be this cumbersome. ...
    (microsoft.public.vc.language)
  • Re: How to port pocket pc 2002 application to windows xp??
    ... edition if the program doesn't use the Microsoft Foundation Classes ... This will let you compile ... string problems. ... make sure UNICODE and _UNICODE are _both_ defined ...
    (microsoft.public.pocketpc.developer)