[fpc-pascal]Synapse for FPC

[Michael Van Canneyt]

On Wed, 23 Jul 2003, Matt Emson wrote:

>
> > So finally, I don't think we're doing a bad job. We'll get there, slowly
> > but surely.
>
> You're all doing a good job, I was just pointing out that these are not new
> issues.
>
> > > Strings.pp for example holds a lot of string related functions that
> really
> > > need to be in sysutils now.
> >
> > They are shared.
> > What exists in as ansistring code in strings is also in sysutils.
>
> Why does this need to exist in two places? This is not helpful.

Because strings already existed in TP.
Delphi merged several 'old' tp units into one: DOS/Strings -> sysutils.

>
> The truth is, I have no right to complain. I'm perfectly capable of using
> FPC as is. It's the people that come to you from other sources that seem to
> be confused (ex-TP people especially.)
>
> Maybe FPC would be simpler if it was 2 or 3 exe's. e.g. fpc_tp[.exe],
> fpc_obj[.exe] and fpc_bd[.exe]. I include an fpc_obj to be polite as I see
> no real need for it. I made my opinion of the obj fpc made clear a long time
> ago ;-)
>
> > > This is a topic that has already been noted. I think it's a time related
> > > problem - the developers have no time to alter what they see as a
> perfectly
> > > normal layout. The problem is that the unit structure has changed
> between
> > > Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or
> invent
> > > it's own scheme. This is something I hope that 1.1 or 1.2 will address!!
> >
> > We do not invent our own scheme:
>
> You don't follow the Borland one. This is therefre your own scheme. A mix
> between Delphi and TP.

We _do_ follow Borland's one, just they have two schemes, separated in time.

We also have two schemes, but not separated in time.

>
> > We have TP units and Delphi units. The TP units are nearly perfect,
> > because TP doesn't change any more. The Delphi units were started in the
> > time that D3 was still the current version, but meanwhile D7 is out and
> > D8 expected, and the units change sometimes wildly. We simply cannot
> > keep up.
>
> LOL!!! I've been using Delphi since v1. This is a complete exageration.
> Between D2 and D5 the unit changes are minor.

Have a look at db.pas.

> D6+ granted, there are a
> excess of new units, and some things change wildly, but in 90% of cases
> where new language features and routines are not being used, the *only*
> change needed is the removal of the 'variants' unit from the uses clause of
> D6+ projects. This is proven by the fact that Synapse Delphi examples are
> all Delphi 7 projects, and all I needed to do was accept the compaint from
> the IDE about properties not existing and remove 'Variants' to compile under
> D5.

This is not 'minor'. e.g. all code setting these 'new' properties would have
to be removed. For a small demo app, this is unlikely to happen, but in
a large project with about 126.000 lines of implementation code, it can
be painstaking...

But I agree that Borland tries to keep backward compatible. And rightly
so.

>
> You should aim for D5. Most large corperations are still using D5.

So do I.

> We will
> not move to D7, we are waiting for D8 for the dotNET implementation. Even
> then, we will likely leave some of our legacy systems in D5.
>
> As for language features. Borland got it right in many places that FPC
> didn't.

This is highly a matter of taste and preference.

> Explicit overloading is an example of this. The only thing I see FPC
> has over Delphi still, is operator overloading. Even then I wonder if I
> really need that feature.

You don't need overloading either, just as you don't need exceptions and
classes and interfaces. This is a matter of taste...

>
> > > > I know. I only not need this yet. That is all. And redesign of this
> > > > huge library needs a time.
> > >
> > > I believe that FPC is in the wrong in many ways. FPC would be a lot
> easier
> > > to support if it stuck to a single Object Pascal target and dialect.
> This is
> > > also a point that I've brought up in the past.
> >
> > This is not correct. The TP object model/language is finished - again,
> > because TP doesn't change. So we have no work on that any more.
>
> I won't ask why TP is still supported because it will doubtless start a
> flamewar. I don't understand though. Have you looked in
> "Borland.public.turbopascal" recently? Not exactly the busiest community
> ever.

Maybe so, but there are still a lot of old projects or code snippets
that people made, and which can be compiled with FPC to be reused again.

The number of times that I get a message from someone thanking us that
we keep fpc compiling TP code e.g. on linux is more than enough
justification for keeping the different modes and language options.

But rest assured, I don't program TP code, I program Delphi code, as I
think it is more 'right'.

Michael.