Op Tue, 29 Jul 2008, schreef Bee:
Could you show me the advantage of having an incompatible string
implementation in FPC 2.4, which will be out after highlander?
Boost the usage of Unicode in FPC that would boost the usage of FPC itself.
Unicode is one of the most demanded features (beside cross platform, 64bit
support, etc) in Delphi since Delphi 7 (2001?). Yet, CodeGear never fulfill
it until Tiburon.
Why would it boost FPC usage?
Okay, here is the deal: From now I'm going to stick my fingers in my ears
until someone says "You should be incompatible because....".
Until now I have heard these valid arguments:
- Delphi's implementation is ugly/non portable.
By providing DELPHI MODE (and other pascal dialects directive), IMO, FPC is
already in the correct way of being different but still united with other
pascal compilers.
The intention of the FPC mode is threefold:
- Allow FPC to be compatible by itself
- Fix the worst quirks in the Delphi dialect
- Disable some FPC features that interfere with compatibility
The FPC modes were never intended to design our own dialect from scratch,
or give the finger to existing code. Any code should compile in FPC mode
with just a few fixes, at least that is how it is intended.
Further, you lack complete understanding of the impact of incompatible
strings. Delphi mode is feasible because in one mode, you can call code in
compiled in other modes.
Good. Now it's time show practical proposals or stop the discussion.
Well, I'm not a compiler expert. Is it possible to keep the "old" string
in Delphi mode and implement "new" string in FPC mode? This way, FPC
could keep (backward) compatibility in Delphi mode and provide the new
(Unicode) implementation in FPC mode. FPC can modify Delphi mode string
later after Delphi shows its mechanism and follow it to get Delphi
compatibility.
I don't consider this a practical solution for Graeme's issue with the
numeric separators, he would still have to wait for 2.4, and we could
implement it compatible anyway in 2.4.
However, I think it's too late to use this scenario since Unicode support in
Tiburon is just a few months away. I think FPC should have done it since
v.2.0. :( Perhaps FPC could think about multiprocessor support using this
scenario. ;)
Agree for the part that an proprietary unicode string would have made
sense then and not now. I would not have done things differently in
hindsight. Postponing it for even more features would have given extra
stress supporting 1.0 and made users impatient waiting for 2.0.
Daniël
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
