[fpc-devel] Russian locale information not compatible with FPC locale variables

[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.

> What is the point to "leading" here?

Be the first object pascal compiler that provide newest technologies 
needed by users. Object pascal users are not as much as Java or C/C++ 
users. But, they are not in very small numbers either. In capitalism 
term, they're asset. By providing pascal compiler that always capable to 
provide new technologies would prevent pascal from its death. That would 
also save millions lines of pascal code being trashed.

> Just to be clear once and forever: We don't want a Netscape vs. Internet 
> Explorer HTML extensions like war. It is our aim to unite rather than to 
> divide the Pascal world more.

You may say that. But look at the reality. You want it or not, users 
would create competition atmosphere by themselves by comparing features. 
There are many faith Delphi developers who still think that FPC is just 
a Delphi follower and Lazarus just another Delphi-like wannabe project 
because FPC/Laz doesn't really provide something that they really need. 
No wonder if those Delphi developers move to other languages (Java, 
Ruby, Python, etc) instead of using FPC. The biggest advantage of 
FPC/Laz over Delphi, IMO, is only the cross platform ability which is 
also available on other languages.

Unite doesn't mean to be a follower. Being different also doesn't mean 
against union. Look at the big picture. There are many pascal developers 
out there that need new technologies being implemented in pascal. No 
matter how much they love the language, if the language doesn't provide 
what they need, sooner or later they would leave pascal for other languages.

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.

> 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.

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. ;)

-Bee-