Re: D8 will be in Unicode: What is unicode?

In article <482b660f$1@xxxxxxxxxxxxxxxxxxxxxx>,
davidn.cgng@xxxxxxxxxxxxxx says...
Jolyon Smith wrote:

Which is why I personally think that embracing a naive "recompile and
fix a few awkward things" approach in Tiburon is a huge mistake and
an even bigger missed opportunity on the part of CodeGear.

In the context of your post (relating to the article), you're once
again complaining about something that no-one is suggesting, ie that
Tiburon's Unicode support is going to (or supposed to) solve Unicode's
weaknesses.

I'm not complaining about that at all.

I'm pointing out (which is not quite the same thing as complaining) that
the underlying philosophy in the Unicode implementation in Tiburon is
based on a fundamentally flawed premise.

Namely that supporting Unicode is a simple question of changing the
nature of the strings in an application.


How else to explain the obsession with handling the ANSI -> Unicode
transition as far as possible in compiler/RTL/implementation changes and
minimising as far as possible the need for any consideration/thought or
otherwise positively take any steps to actually support Unicode other
than to just recompile.

Even more bemusing when you consider the unavoidable fact that even if
your application DOES - as a result of the approach in Tiburon - manage
to compile without needing any significant remedial work to address the
mandatory Unicode personality switch of Char and String, it will STILL
not be enough to support Unicode if your application is one of those
weird edge-case ones that uses a database or communicates with or
exchanges string data with any other application or has anything other
than the most rudimentary input validation or string
handling/processing.


The ONLY reasonable argument for the approach is that it made the job of
implementing it easier for CODEGEAR (although already obvious for those
with a ticket for the clue train, it became still clearer following the
spate of blog postings on the subject a few months ago which then
mysteriously dried up).

But any argument that might have justified a degree of compromise and
pain (for users that don't strictly need Unicode but are to be compelled
to adopt it in order to stay current) for the sake of speedy delivery
lost all currency some time ago - by which I mean YEARS.

Having waited this long for Unicode support, the least that the Delphi
community deserved, surely, was to have it finally arrive as dang-near
perfect - FOR THEM and their needs - as possible.


As it is, not only is it still years too late - in many peoples view -
but even then/now it clearly wasn't as easy as CodeGear deluded
themselves into believing it would be, otherwise we would all be using
it already and not STILL waiting for it.
.

Relevant Pages

  • Re: Meanwhile, sounds like the unicode update is coming along ...
    ... They will think that "Tiburon creates Unicode applications, ... but they most likely won't properly SUPPORT Unicode. ... I don't find the idea that going forward 'string' will mean unicode ...
    (borland.public.delphi.non-technical)
  • Re: Meanwhile, sounds like the unicode update is coming along ...
    ... entered string and perform some processing on that string, ... Unicode one is a great deal harder. ... IMO that's no harder than make your Ansi code handle different code ... To support Unicode, I change it. ...
    (borland.public.delphi.non-technical)
  • Re: Problem using wchar_t and wprintf
    ... whole unicode, you don't know *how* it does it. ... glibc does have the macro defined. ... wchar_t code won't break if the system doesn't support unicode. ... friend, it's useless. ...
    (comp.lang.c)
  • Re: Turbo was a great idea
    ... application that can store Japanese/Chinese/Korean data in a database. ... We used ADO and since VCL is not Unicode enabled, ... has customers in more than one country will need to support Unicode. ...
    (borland.public.delphi.non-technical)
  • Persian Fonts in Office 2004
    ... International control panel for Dari and Pashto fonts, ... but Office X does not support Unicode. ... with Persian fonts? ...
    (microsoft.public.mac.office)