[fpc-pascal]Synapse for FPC

[Matt Emson]

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

You only therfore need sysutils, *or* the old scheme. Not both. I understand
why this was done by Borland. Legacy is hard to break, and D1 broke with
legacy.

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

And therefore your own scheme. It's not the current, nor the old, but a
hybrid on the Windows platform, and on the Linux/BSD platform I expect you
*do* have some of your own scheme in place, I have never looked.

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

The truth is, I have ported extermely large apps from D1 to Delphi 3 and 4.
There is no significant problem, so long as you didn't do nasty hacky things
with the implementation of TTable etc.

Class hierarchies have changed, but this should and does not matter. The
code, so long as it does not break any rules, still compiles. D1 was the
biggest DB change, and D1 apps are fairly trivial to convert to D3, so long
as you respect the language features that have changed. From D2 to D5 is
pretty straight froward too.

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

The IDE will remove all unknown properties from the DFM when streaming it
in. The rest is accademical. Most properties that have been introduced are
to do with support for unicode and bidirectional languages. Borland are very
good at not adding nasty additional features. It's thrid parties that
usually excel at that.

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

If you mainly use native Borland VCL components, the transistion from D2 to
D5 is fairly trivial. The migration from D7 back to D5 is also trivial,
although you will run into incompatibilities due to language features that
have been added (the new $if and enum types that allow indexes to be
specified being two that crop up frequently.) I've ported Dave Jewels GDI+
examples from the Delphi Magazine to Delphi 5, and he uses just about every
new feature he can find. That was pretty trivial.


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

Sure. Overloading should be used sparingly (as James Mills proved last
week.)

Exceptions are needed. Classes are needed. Interfaces are usefull. Not my
taste, just a fact. They are too well established not to argue on.

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

Any many more that do not work due to the flat 32bit memory architecture.
That's a bit like saying "I can use COBOL.Net to compile my old mainframe
apps for Windows." Maybe even like saying "I can recompile my old VB6 apps
in VB.Net." ;-)

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

Sure. But you could create a 'TP' branch of the compiler, remove it from the
main compiler soure tree and leave it for the legacy peeps. If you got the
seperation right, you could still share sections of the engine, just not the
code parser and such. This would then focus FPC on the here and now, and you
could remove the legacy from the unit tree.

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

You got my vote ;-)

Matt