[fpc-pascal]Synapse for FPC

[Marco van de Voort]

[some minor remarks]

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

Opinions differ. But the IDE and parts of the compiler itself are TP.

If we had a lot of hard working people, we could make a nice new set of 
platform dependant units, and more and more TP units would become legacy.

Do you volunteer?
 
> 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.

We do in general. But 1.0.x is frozen, and we have to make adjustments for
the fact that we have a strict visual<-> non visual separation, and a lot
more platforms (and processors in the near future).

Giving that up is no option. It is the main edge that FPC has over Borland,
except the doubtful one that it is free.

> This is therefre your own scheme. A mix between Delphi and TP.

No it isn't. It is roughly a superset of Delphi and TP, so also a superset
over Borlands scheme.
 
> > 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.

So ansistrings, widestrings, dynamic arrays etc changes are minor?

How many differences are there inside the core units (like sysutils)
compared to e.g. D3? What are the deviances of FPC except adding a few extra
units, and putting some platform dependant stuff in extra units?

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

Try to compile something from Jedi. They still support D5, but I sometimes
wonder how long. FPC is still getting more compatible to newer Delphi's
fast, I don't really see the problem.

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

The synapse author already said in this thread that Synapse is a suite
that already exists for a couple of Delphi versions.

> You should aim for D5. Most large corperations are still using D5. 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.

This is not common IMHO. While in my surroundings there are indeed a lot of
people/companies that don't upgrade, I don't see a firm separation somewhere
between D5 and D6+.
 
> As for language features. Borland got it right in many places that FPC
> didn't. 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.

I don't understand all this. Sure, FPC is lagging behind in features, but 
"Borland got it right in many places that FPC didn't". Where does this come
from?
 
> > > 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.

Simple. We are not a major vendor, but providing a suite for a certain niche
(roughly people with Borland affinities and demands that are not met by
Borlands current product lines. Think portability, legacy, total access to
source including compiler etc, e.g. because of embedded world). That and the
Open Source price advantage are our only plusses over Borland. 

So if it is a from a worldwide IT perspective, it doesn't have to be a niche
for us. We are already a niche :-) 

There are of course also historical reasons. The compiler is already Delphi
compatible


The only way to improve the situation is more collaborators, and/or a much
higher users that e.g. occasionally does some work for FPC (update a certain
unit, make an interface etc). The situation nowadays is already much better
than it used to though say a few years back, on the other hand, there is a
lot more to do nowadays too.