Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <[EMAIL PROTECTED]> 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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
