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

[Daniël Mantione]

Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:

> On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <marcov at stack.nl> wrote:
>>> same boat.  I don't see any point in waiting for Delphi, after all, we
>>> may NOT look at their implementation anyway!
>>
>> No, but we can try to keep compability.
>>
>>> Is there any FPC discussions as to how this is going to be tackled and
>>> what implications there are etc..?
>>
>> There have been, but they are now postponed till we have real Tiburon usage
>> data.
>
> So FPC plans to always be worse off than Delphi. :-(  I really think
> playing 'catchup' with somebody like Delphi is not a good thing. They
> have different goals as far as I can see, plus their future doesn't
> look bright (for a very long time now).  Delphi tries to compete with
> Microsoft using Microsoft's own tool (.NET).  We all know how that
> turns out when anybody tries to compete with Microsoft.  Because of
> that, Delphi language features are very behind compared to the
> developer demand.  So now FPC wants to be even more behind, because we
> need to wait for Delphi to one day get there act together.  :-(

FPC behind? What are you talking of man? :)

Waiting until we know more about the Delphi implementation is in the 
interrest of everyone here. Borland, oops, Codegear, whoops, Embarcadero, 
might have strange plans, but Delphi users remain important for FPC. Not 
everyone has completely switches to FPC like you and even you benefit from 
being able to use more external code. Code exchange is extremely 
important.

Note we need a major revision anyway to introduce these changes.

> As far as I heard we are already incompatible with Delphi regarding
> Generics (I don't know generics, I just heard of them). So even though
> FPC has Generics for some time, nobody can use it, because it's
> incompatible with Delphi.

People who need their code compilable with Delphi cannot use generics 
indeed. So what, they can use both Delphi and FPC if they keep their 
code clean of compiler specific features. But, doing strings incompatible 
with Delphi means Delphi users cannot use FPC. Because any program uses 
strings.

> Unicode is another issue. Delphi dictates there design decisions based
> on Windows only. FPC targets multiple platforms, so we should target
> our implementations based on OUR requirements.

Agree, but note that one of our requirements is code exchange with Delphi.

> An open source project trying to be compatible with a commercial
> product is simply a pipe dream.  That's my thought on the subject, but
> that irrelevant I guess because I have no say in the FPC core team and
> there direction.  I'm also getting a bit off topic here..
>
>> Yes. You can make tests using widestrings. When it is working, translate all
>> literals to utf-8. Do so for preferably all sysutils,dateutils and strutils
>> string routines, but start with the more important ones. Probably you can
>> see if there are already routines testing this for ansistring in the
>> testsuite and build on that.
>
> I'll have a look at the current testsuite to see what's there...
>
>> It will help me/us to start making UTF-8,16 versions of the RTL routines.
>> That work is parallelizable with the compiler work, and these will have to
>> be done anyway sooner or later, and fairly independant of the exact outcome
>> of the string types.
>
> Exactly my point! And if you want some code to look at (which you may
> legally do, not like Delphi code), have a look at MSEIDE, Lazarus and
> fpGUI for implementation examples of some functions.

Good. MSEIDE is quiet a bit ahead because it made the switch to 
widechar/strings from the start.

Daniël