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

[Marco van de Voort]

> On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <marcov at stack.nl> wrote:
> > 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. :-( 

Well, of course. We have more requirements!? Multi-platform and compability
to self and Delphi. But that we pull that off is also one of our main (if
not THE) strengths.

And in the past it has proven that it pays to be compatible, and to be not
rash in major course decisions because of pressure to "immediately" do
something.

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

We have Delphi compatibility as a major point, and it pays off. We are the
only smaller development project that is not stewarded by some firm that has
commercial components written for it.

Also, the clear direction of compability limits the "design by committee"
problem a bit, where you get a feature laden, but unusuable product.

> Delphi tries to compete with Microsoft using Microsoft's own tool (.NET). 

Tiburon comes without .NET.

> We all know how that turns out when anybody tries to compete with
> Microsoft. 

We also have a Windows compiler.

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

We are not a commercial company, and even a commercial company doesn't
automatically only cater to the herd. There are specialized commercial
companies too.

You say it yourself, you can't compete with Microsoft, and we need an edge
over the zillion of useless Open Source development projects somehow.

A clear direction, our relative independance and the fact that we dare to
take impopular choices is our main edge there. That, and the influx from a
major external commercial codebase. 

Let's not ruin that.
 
> 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.

We will see how that pans out in time. Maybe we'll support Delphi's syntax
too in time. Wouldn't be the first time.
 
> 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.

Yes. But while we don't have the exact requirements that Delphi does, we do
have Delphi compability as major feature. Period.

All the major open source codebases (Jedi, Indy, VST, the remobjects stuff,
whatever is still active of the TurboPower stuff etc) will go Tiburon sooner
or later. If you want to be the messenger that tells them that they have to
manually insert a conversion in each procedure, or fork the codebase for
FPC, I can give them your email address.

The same ackward position is created for more FPC oriented packages that
also support Delphi (like e.g. TDBF).

A lot of former deviations from Delphi compatability have been changed back
to compatible in time (e.g. the procvar stuff, the required @ which is still
in objfpc) except for some of the most lowlevel details, for exactly such
reasons.
 
> An open source project trying to be compatible with a commercial
> product is simply a pipe dream. 

Well first, I don't think so, but also what are you suggesting? Becoming the
a small "last stand" for Pascal ? 

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

Yes, we can stuff the rough routines in a few temporary utitlity routines
even (sysutilsunicode and strutilsunicode or so), till the rest is ready to
go native. Or postfix them with encoding for time being and stuff them in
sysutils/strutils.

But first we need a set of tests, then make the routines, and then we'll see
where to stuff them.