Marco van de Voort marcov at stack.nl
Sun Aug 19 15:10:32 CEST 2001

> > Matt, I really don't understand why FPC lessening the strictness of
> Delphi's
> > implementation of OOP is hurting anything.
> Because no one uses the standard. If no one uses the standard, doesn't that
> tell you something about the standard? I.e. undesirable. I used to program
> in ADA, and to be honest it was a nightmare, mainly because some board
> somewhere had sat down and designed it. It was all over the place IMHO.

You might be right if Delphi's standard was fixed. However it still fluctuates
per version. Anything that doesn't break backwards compability could be
in the next Delphi version. We saw that with Overloading :-)
> > I mean, you can still declare
> > fields before methods if you want, but it's not necessary.
> Because Delphi is probably the most widely used Pascal compiler (Turbo
> Pascal given) today.

Purely copying doesn't work. Tapping in into the sourcebase does. So it should
eat Delphi programs, but shouldn't be limited by what Delphi can.

The implementation of the various forms of overloading by Borland is pretty
much proof of that.
> > Maybe it would be a good idea to force this strictness in {$MODE DELPHI},
> but I
> > think it would be a bad idea to also force it in {$MODE OBJFPC}.
> One of the major problems with FPC is that it tries to do too many things.
> Too many cooks spoil the broth etc. If FPC focused on a standard (and the
> Borland standard is one I would like to see aimed for, that's both Turbo and
> Object Pascal) then the compiler would be stronger.

That is what it pretty much does. The extensions are only a few %%. As long
as that balance remains sound, I don't see why that would spoil the "broth"

FPC 1.1 eats thousands (and sometimes already 10s of thousands!) lines of
Delphi code without problems with the compiler (libraries are an entirely
different chapter)

> Implementing standards that no one uses is a waste of time and resources.

We don't have a legal version of the Delphi version. The original standard
was available in paper and free to use.

> Implementing additional compatibility modes is not worthwhile. If we want
> to use GPC, we can download it etc. Besides, surely the Extended Pascal
> standard would be a better one to aim for.

The extended standard is too much work. But the original standard is within
reach. It only requires very few changes, and some RTL changes (that shouldn't
be enabled standard, only under IFDEF)

Personally I think this is all academic. In practice FPC supports Delphi
with a few extensions.  The main probably are the libraries, and will remain
for a very long time. The core team is increasingly getting occupied with
the compiler, creating new targets, and maintaining the core RTL.

We need more donations to extend the libraries.  Same with Lazarus, which is
also need more contributors.

> > On a side note, GPC is supposedly going to implement OOP (the variety
> > described in the working draft) and treat .pp files as Pascal sources.
> GPC is next to useless in most normal ussage.

They have one large advantage IMHO, and that is not the one everybody thinks
it is: they can directly access C and C++ (and maybe even Java) headers.
If they ever get up to speed with FPC that could be a major disadvantage.

> > But I've never tried GPC, primarily because it sounds like it would be
> hard to
> > get set up but also because I feel it's hypocrisy to make a Pascal
> compiler
> > with C.
> Save yourself the bother ;-) Dont..

Not the first few years. They are pretty much in a kind of 0.99.5 or even
earlier stage, but then multiprocessor and with a horrible compiler build
process. Also GPC development seems to be stalling.

More information about the fpc-pascal mailing list