From: "Marco van de Voort" <[EMAIL PROTECTED]>
Unicode RTL is needed for people who want to develop unicode applications
from the beginning. In such case the developer will be aware of unicode
and
will write correct code.
All correct, BUT
1) it is not Unicode RTL but Unicode FPC/Lazarus.
2) it is not backwards compatible. We have to take care of more people's
need
than just the ones that urgently need Unicode to be as easy as possible.
3) thus creating an huge support problem
4) as mentioned before (and forgotten by me earlier) even UTF32 is
not 100% fixed width
There is no magic solution to make unicode RTL compatible with existing
apps
or libs.
Correct. But what is then the use of stuffing it into the entire codebase?
That extra work is then useless
Unicode RTL will be an option for people who really need it.
Unicode is. I'm not sure "Unicode RTL" is.
IMHO RTL code base must be the same for ansi and unicode. To build
unicode
RTL some define must be used.
As said, since legacy RTL code doesn't become magically unicode, maybe it
is
better to keep it separate, and overload a few funcs (like filesystem) if
necessary at all (on *nix, use utf8).
I agree. There is no need to make existing RTL APIs unicode aware, because
there will be no compatibility with existing apps in any case.
So how about to add alternative unicode versions of RTL APIs via overloading
or via adding some suffix (eg. Assign and AssignW, TStringList and
TStringListW - like in WinAPI)?
There are following benefits in such approach:
1. It will be possible to develop unicode apps using these APIs.
2. There will be only one RTL.
3. There will be single source tree.
4. It will not break existing RTL code.
Yury Sidorov.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
