Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

etrusco
On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voort <[hidden email]> wrote:

> In our previous episode, Mark Morgan Lloyd said:
>> > (remember recent discussion about IfThen pseudo-function).
>>
>> More relevant to your situation, I remember discussion about adding an
>> identifier to WITH to use as an explicit shortcut, i.e. something like
>>
>> with foo= bar do
>>    foo.someField := ...
>
> Not relevant since the With code in this case must remain delphi compatible.

I, for one, would vote in favor making the documentation discourage
the use of 'with' and adding a warning in compiler...

Best regards,
Flávio
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Michael Van Canneyt


On Wed, 24 Feb 2016, Flávio Etrusco wrote:

> On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voort <[hidden email]> wrote:
>> In our previous episode, Mark Morgan Lloyd said:
>>> > (remember recent discussion about IfThen pseudo-function).
>>>
>>> More relevant to your situation, I remember discussion about adding an
>>> identifier to WITH to use as an explicit shortcut, i.e. something like
>>>
>>> with foo= bar do
>>>    foo.someField := ...
>>
>> Not relevant since the With code in this case must remain delphi compatible.
>
> I, for one, would vote in favor making the documentation discourage
> the use of 'with' and adding a warning in compiler...
I don't see why.

I use "with" extensively. I see nothing wrong with this useful construct.

The problem of the 'new identifier inserted in scope' exists, but is rare
enough for me to tip the balance in favour of using "with". It has maybe
happened once or twice in 25 years that I got bitten by it.

I find that perfectly acceptable.

For people that worry about this, the solution of Jonas should be ample to
detect/avoid mistakes.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
In reply to this post by Sven Barth-2
Good, I see yours points.
Not so impressed, don't really share. The community spirit does not inspire confidence.

I stay with FPC/Lazarus for some fun projects like FBProfiler (https://sourceforge.net/projects/fbprofiler/) but for "real world programs" the migration is canceled until better times.
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

etrusco
In reply to this post by Michael Van Canneyt
On Wed, Feb 24, 2016 at 9:00 AM, Michael Van Canneyt
<[hidden email]> wrote:

>
>
> On Wed, 24 Feb 2016, Flávio Etrusco wrote:
>
>> On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voort <[hidden email]>
>> wrote:
>>>
>>> In our previous episode, Mark Morgan Lloyd said:
>>>>
>>>> > (remember recent discussion about IfThen pseudo-function).
>>>>
>>>> More relevant to your situation, I remember discussion about adding an
>>>> identifier to WITH to use as an explicit shortcut, i.e. something like
>>>>
>>>> with foo= bar do
>>>>    foo.someField := ...
>>>
>>>
>>> Not relevant since the With code in this case must remain delphi
>>> compatible.
>>
>>
>> I, for one, would vote in favor making the documentation discourage
>> the use of 'with' and adding a warning in compiler...
>
>
> I don't see why.
>
> I use "with" extensively. I see nothing wrong with this useful construct.
>
> The problem of the 'new identifier inserted in scope' exists, but is rare
> enough for me to tip the balance in favour of using "with". It has maybe
> happened once or twice in 25 years that I got bitten by it.
>
> I find that perfectly acceptable.
>
> For people that worry about this, the solution of Jonas should be ample to
> detect/avoid mistakes.
>
> Michael.

I loved 'with' while I was learning Delphi/Pascal and hated after the
first few months since using it professionaly. I truly believe it
warrants/deserves some advice in the documentation, for the beginners.
With the code completion in Lazarus there's even less reason to use it
- besides any possibly missing compiler optimization...

Best regards,
Flávio
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
etrusco wrote
I loved 'with' while I was learning Delphi/Pascal and hated after the
first few months since using it professionaly. I truly believe it
warrants/deserves some advice in the documentation, for the beginners.
With the code completion in Lazarus there's even less reason to use it
- besides any possibly missing compiler optimization...
Indeed, there are no big differences between "uses" and "with" in Object Pascal, "using namespace" in C++ or "using" in C#.
For example, my short article "Crack C# namespaces in 30 seconds"
http://arbinada.com/main/en/node/1416
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Mark Morgan Lloyd-5
In reply to this post by Bo Berglund
Bo Berglund wrote:
> On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth
> <[hidden email]> wrote:
>> What would really help here would be the warning that Jonas mentioned...
>> For the above you could just use a local variable and be done with it. No
>> need to try to "fix" the with-statement.
>
> I really fully agree!

Perhaps a hint when a single WITH is used and a warning if they're
nested. After all, it /is/ a standard part of the language.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Sven Barth-2
In reply to this post by Bo Berglund

Am 24.02.2016 12:30 schrieb "Bo Berglund" <[hidden email]>:
>
> On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth
> <[hidden email]> wrote:
> >
> >What would really help here would be the warning that Jonas mentioned...
> >For the above you could just use a local variable and be done with it. No
> >need to try to "fix" the with-statement.
>
> I really fully agree!
> When working a few years back I had to trace through a piece of code
> where the original author had done something like:
>
> with My.Stuff.something do
>   with My.Other.Stuff.somethingelse do
>     with myyetanother do
>     begin
>       someproperty := xxx;
>       ....
>       ....
>     end;
> It was totally impossible to make sense of anything while debugging!

Just as a sidenote: Lazarus handles withs correctly while debugging ;)

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Sven Barth-2
In reply to this post by Mark Morgan Lloyd-5

Am 24.02.2016 16:44 schrieb "Mark Morgan Lloyd" <[hidden email]>:
>
> Bo Berglund wrote:
>>
>> On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth
>> <[hidden email]> wrote:
>>>
>>> What would really help here would be the warning that Jonas mentioned...
>>> For the above you could just use a local variable and be done with it. No
>>> need to try to "fix" the with-statement.
>>
>>
>> I really fully agree!
>
>
> Perhaps a hint when a single WITH is used and a warning if they're nested. After all, it /is/ a standard part of the language.

A warning when another identifier is shadowed might be more useful as Jonas said. Cause then one could find all problematic identifiers and not just all withs...

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Mr Bee
In reply to this post by Marco van de Voort
Pada Rabu, 24 Februari 2016 18:40, Marco van de Voort <[hidden email]> menulis:



> In our previous episode, Mark Morgan Lloyd said:
> > > (remember recent discussion about IfThen pseudo-function).
> >
> > More relevant to your situation, I remember discussion about adding an
> > identifier to WITH to use as an explicit shortcut, i.e. something like
> >
> > with foo= bar do
> >    foo.someField := ...

> Not relevant since the With code in this case must remain delphi compatible.


Sometimes I just don't understand the policy of FPC devs about Delphi compatibility. In some cases, they said FPC isn't a slave of Delphi, FPC should have better goal than Delphi, there's the Delphi way and there's the FPC way, breaking old codes is consequence of a change, bla bla bla…. 

But in some other times, like now in this case, the 'with' case, they said that it must be Delphi compatible, don't break old codes, keep the compatibility, bla bla bla…. Like when they responded to my proposal to set {$J-} as default because that's how a const is suppose to be. And it's the default now on Delphi as well.

Maybe FPC devs should give us the "rule" or policy about what kind of change that is acceptable and not acceptable. So when we think of something new we could look at the rule and if it's doesn't comply then we don't need to bother to propose.

Regards,

–Mr Bee


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Sven Barth-2

Am 25.02.2016 02:00 schrieb "Mr Bee" <[hidden email]>:
> Maybe FPC devs should give us the "rule" or policy about what kind of change that is acceptable and not acceptable. So when we think of something new we could look at the rule and if it's doesn't comply then we don't need to bother to propose.

There is not one rule. It always depends on the context. E.g. here the code needs to stay compatible with Delphi does assign a FPC only feature won't help. On the other hand the {$J-} change would.not be backwards compatible as older Delphi versions had it enabled as well. In essence it's always decided on a case by case base what is more important.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
In reply to this post by Mr Bee
Mr Bee wrote
Sometimes I just don't understand the policy of FPC devs about Delphi compatibility. In some cases, they said FPC isn't a slave of Delphi, FPC should have better goal than Delphi, there's the Delphi way and there's the FPC way, breaking old codes is consequence of a change, bla bla bla…. 
In the absence of standard, there is no way.
All depends on several core developers (FPC) or on corporate policy (Delphi).
The Delphi way is less poor but both are risky.

The absence of standards is the most weak point of Object Pascal/Delphi and its "standard" libraries.
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Bls: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Mr Bee
In reply to this post by Sven Barth-2
So, which Delphi that FPC keep the compatibility with? The old Delphi or the new Delphi? How old is old? How new is new?
 

–Mr Bee



Pada Kamis, 25 Februari 2016 14:05, Sven Barth <[hidden email]> menulis:


Am 25.02.2016 02:00 schrieb "Mr Bee" <[hidden email]>:
> Maybe FPC devs should give us the "rule" or policy about what kind of change that is acceptable and not acceptable. So when we think of something new we could look at the rule and if it's doesn't comply then we don't need to bother to propose.
There is not one rule. It always depends on the context. E.g. here the code needs to stay compatible with Delphi does assign a FPC only feature won't help. On the other hand the {$J-} change would.not be backwards compatible as older Delphi versions had it enabled as well. In essence it's always decided on a case by case base what is more important.
Regards,

Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Jonas Maebe-2

Mr Bee wrote on Thu, 25 Feb 2016:

> So, which Delphi that FPC keep the compatibility with? The old  
> Delphi or the new Delphi? How old is old? How new is new? 

We added {$mode delphiunicode} for newer Delphi versions (generally  
2009+), so I propose to make {$j-} the default there.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Florian Klämpfl
In reply to this post by Mr Bee
Am 25.02.2016 um 01:59 schrieb Mr Bee:

> Pada Rabu, 24 Februari 2016 18:40, Marco van de Voort <[hidden email]> menulis:
>
>
>
>> In our previous episode, Mark Morgan Lloyd said:
>> > > (remember recent discussion about IfThen pseudo-function).
>> >
>> > More relevant to your situation, I remember discussion about adding an
>> > identifier to WITH to use as an explicit shortcut, i.e. something like
>> >
>> > with foo= bar do
>> >    foo.someField := ...
>>
>> Not relevant since the With code in this case must remain delphi compatible.
>>
>
> Sometimes I just don't understand the policy of FPC devs about Delphi compatibility.

I guess in this case it means: the code must be still compilable with delphi so any FPC extension
does not help.

> In some cases,
> they said FPC isn't a slave of Delphi, FPC should have better goal than Delphi, there's the Delphi
> way and there's the FPC way, breaking old codes is consequence of a change, bla bla bla….
>
> But in some other times, like now in this case, the 'with' case, they said that it must be Delphi
> compatible, don't break old codes, keep the compatibility, bla bla bla…. Like when they responded to
> my proposal to set {$J-} as default because that's how a const is suppose to be. And it's the
> default now on Delphi as well.
>
> Maybe FPC devs should give us the "rule" or policy about what kind of change that is acceptable and
> not acceptable. So when we think of something new we could look at the rule and if it's doesn't
> comply then we don't need to bother to propose.

"FPC devs" is only the people who do the work. Their/Our opinion e.g. regarding Delphi compatibility
is as diverse as here on the mailing list. But as we prefer to spent our time in coding than to make
a useless point in a mailing list, we find normally an agreement. So as Sven said, everything is
decided case by case.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Michael Van Canneyt
In reply to this post by Serguei TARASSOV


On Thu, 25 Feb 2016, Serguei TARASSOV wrote:

> Mr Bee wrote
>> Sometimes I just don't understand the policy of FPC devs about Delphi
>> compatibility. In some cases, they said FPC isn't a slave of Delphi, FPC
>> should have better goal than Delphi, there's the Delphi way and there's
>> the FPC way, breaking old codes is consequence of a change, bla bla bla…. 
>
> In the absence of standard, there is no way.
> All depends on several core developers (FPC) or on corporate policy
> (Delphi).
> The Delphi way is less poor but both are risky.
Oh, why is that ?

>
> The absence of standards is the most weak point of Object Pascal/Delphi and
> its "standard" libraries.

We could not be more in agreement.

However, I wish to point out that FPC here is always in the disadvantage:

Borland/Inprise/Embarcadero/Idera has consistently denied to cooperate on this.
(whether or not this is a company policy, or because they simply ignore us, I do not know).

When FPC implemented a language feature first, they later implemented it differently.

To give an example:
When Jonas designed the objective C classes for Mac OS X, he explicitly mailed them to ask
what they were going to do. He got a noncommittal answer.

By contrast, when we implement a feature that Delphi has, we always implement it in a
compatible way in $MODE Delphi.
When doing base classes, we make sure that we provide all identifiers that Delphi
provides, so your code compiles.

If someone reports a missing identifier, we always attempt to implement it.

I don't see what we can do more ?

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
Michael Van Canneyt wrote
> The Delphi way is less poor but both are risky.
Oh, why is that ?
I.e. because of third-party frameworks.
When programmer stays with FPC and its libraries only, the support and the compatibility are not a big problem (but some libraries become abandoned or some bugs stay in state "fix it yourself"). For "real world programs" many third-party frameworks are used and even the source code doesn't solve the problem. The case with UniDAC is in the start of this topic but we have about 20 other third-party libraries in our codebase. Any responsible engineer should minimize such technical risks.
So the Delphi way is a less risky IMO.

> The absence of standards is the most weak point of Object Pascal/Delphi and
> its "standard" libraries.
We could not be more in agreement.

However, I wish to point out that FPC here is always in the disadvantage:

Borland/Inprise/Embarcadero/Idera has consistently denied to cooperate on this.
(whether or not this is a company policy, or because they simply ignore us, I do not know).

When FPC implemented a language feature first, they later implemented it differently.

To give an example:
When Jonas designed the objective C classes for Mac OS X, he explicitly mailed them to ask
what they were going to do. He got a noncommittal answer.

By contrast, when we implement a feature that Delphi has, we always implement it in a
compatible way in $MODE Delphi.
When doing base classes, we make sure that we provide all identifiers that Delphi
provides, so your code compiles.

If someone reports a missing identifier, we always attempt to implement it.

I don't see what we can do more ?
I don't blame someone at all.
My point is only the regret about the absent of standards on the language and common libraries like in C/C++.
When there is no standards in law "de jure", the most popular implementation becomes the "standard" in fact. I suppose, that Delphi is the standard in fact the last 15 years because of the large community and the large developers base (1M at least).

The same reason we use English in mailing lists but not French or Russian regardless the wide Russian Delphi community.

So in my taste the {$MODE DELPHI} should have been support not only language features but all common libraries too, at least RTL/DB. All FPC extension/modifications could be added in FPC mode. Not easy but reliable.
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Michael Van Canneyt


On Sun, 6 Mar 2016, Serguei TARASSOV wrote:

> I don't blame someone at all.
> My point is only the regret about the absent of standards on the language
> and common libraries like in C/C++.
> When there is no standards in law "de jure", the most popular implementation
> becomes the "standard" in fact. I suppose, that Delphi is the standard in
> fact the last 15 years because of the large community and the large
> developers base (1M at least).
>
> The same reason we use English in mailing lists but not French or Russian
> regardless the wide Russian Delphi community.

Tut ti vibral plohoi primer, po-moemu... :)

A bad example. Plenty of language-specific forums exist.
They live, and no-one denies them their existence.

> So in my taste the {$MODE DELPHI} should have been support not only language
> features but all common libraries too, at least RTL/DB. All FPC
> extension/modifications could be added in FPC mode. Not easy but reliable.

It's simply not possible as long as you allow to mix modes on a per-unit basis.

I have said it before:
{$MODE XYZ} says something about available language constructs when
compiling. Not about available identifiers in units that you use.
This is a fundamental difference.

Not to mention the maintenance nightmare 2 sets of units would present us with.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
Michael Van Canneyt wrote
Tut ti vibral plohoi primer, po-moemu... :)

A bad example. Plenty of language-specific forums exist.
They live, and no-one denies them their existence.
Ты прав, есть много локализованных форумов, но...
You're right there are many language specific forums but English became the standard "in fact". I see the trend of last 10 years when Russian developers who lived in Russia write yours blogs in English only.
Sad but c'est la vie...

> So in my taste the {$MODE DELPHI} should have been support not only language
> features but all common libraries too, at least RTL/DB. All FPC
> extension/modifications could be added in FPC mode. Not easy but reliable.

It's simply not possible as long as you allow to mix modes on a per-unit basis.

I have said it before:
{$MODE XYZ} says something about available language constructs when
compiling. Not about available identifiers in units that you use.
This is a fundamental difference.

Not to mention the maintenance nightmare 2 sets of units would present us with.

Michael.
{$MODE DELPHI} could switch to {$IFDEF DELPHI} conditional compilation or something similar with the defines corresponding of Delphi compiler version compatibility, i.e. D15 or so.
I see that supporting two version of units is hard much less the units interfaces was never copied from earlies version of Delphi AFAIK. It's a little easier when starting from fork.
Actually I should support D7/FPC and XE10 compilation of few dozen units and and despite the fact that they started with a fork it's not easy at all.
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: *** GMX Spamverdacht *** Re: Bls: Bug in FPC 3.0.0

Jürgen Hestermann
Am 2016-03-06 um 17:00 schrieb Serguei TARASSOV:
 > You're right there are many language specific forums but English
became these
 > standard "in fact". I see the trend of last 10 years when Russian
developers
 > who lived in Russia write yours blogs in English only.
 > Sad but c'est la vie...

Why is this sad?

I like it that there is meanwhile a common sense
about which language to use as an international language
and that more and more people all over the planet
know at least a little bit English so that I can
communicate with them.

I would even vote for dropping other foreign languages at school
and invest the saved time to improve English.
This way a global communication will become much easier.
Those who like other languages can learn them in their spare time
if they want and have talent but it should not be forced on everybody.

If the audience is restricted to one country only then of course the
native language of these people can/should be used.
But with globalisation this becomes more and more unlikely.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Sven Barth-2
In reply to this post by Serguei TARASSOV


Am 06.03.2016 17:00 schrieb "Serguei TARASSOV" <[hidden email]>:
> >> So in my taste the {$MODE DELPHI} should have been support not only
> >> language
> >> features but all common libraries too, at least RTL/DB. All FPC
> >> extension/modifications could be added in FPC mode. Not easy but
> >> reliable.
> >
> > It's simply not possible as long as you allow to mix modes on a per-unit
> > basis.
> >
> > I have said it before:
> > {$MODE XYZ} says something about available language constructs when
> > compiling. Not about available identifiers in units that you use.
> > This is a fundamental difference.
> >
> > Not to mention the maintenance nightmare 2 sets of units would present us
> > with.
> >
> > Michael.
>
> {$MODE DELPHI} could switch to {$IFDEF DELPHI} conditional compilation or
> something similar with the defines corresponding of Delphi compiler version
> compatibility, i.e. D15 or so.
> I see that supporting two version of units is hard much less the units
> interfaces was never copied from earlies version of Delphi AFAIK. It's a
> little easier when starting from fork.
> Actually I should support D7/FPC and XE10 compilation of few dozen units and
> and despite the fact that they started with a fork it's not easy at all.

You can't influence precompiled units. Also I wouldn't even remotely want to maintain such a mess.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12