[fpc-pascal]Synapse for FPC

[Matt Emson]

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

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

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.

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

> Now, the Delphi language compatibility is being worked on. There the
> situation is more complex as Delphi itself still changes. What is more,
> there has been feature overlap: FPC had features that delphi didn't
> have, and vice versa. Borland seemed to take pleasure in implementing
> something that already existed in FPC in a different way in Delphi.
>
> > As for TCP/IP implementations on differing platforms - surely providing
a
> > uniform interface for FPC would solve this (IIRC that was the idea) and
this
> > could then be wrapped into a Delphi alike interface for use by Synapse
etc.
>
> It exists. See ssockets.pp in the FCL.

I assumed as much.

Matt