Hello,

Sorry, my previous example was not complete.
Here is a problem detected when compiling UniDAC 6.2.8. Taken from real code in VirtualTable.pas

program Project1;
{$MODE DELPHI}
uses
  SysUtils, Classes, DB;
procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
var
  F: TField;
  FieldDef: TFieldDef;
begin
  begin
    with F do
    begin
      FieldDef := FieldDefs.AddFieldDef;
      // in FPC 3.0.0 Error: No member is provided to access property
      // in FPC 2.6.4 compiles OK
    end;
  end;
end;
begin
end.

-----

The problem is in your code and the use of WITH, as I surmised in my previous mail.

In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef. The code compiles ok.

In 3.0.0, FieldDef is a NEW READ-ONLY property in TField. Because of the WITH, the compiler resolves FieldDef to this property, but it is read-only, an so it gives an error.

Change your code to

Var
    AFieldDef: TFieldDef;

and

      AFieldDef := FieldDefs.AddFieldDef;

and all will be well.

Michael.

Michael Van Canneyt wrote

I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4.
You cannot recommend them to change code.
There are many other errors during compile, if someone is interesting I can provide the list.

So the problem is in DB unit.
The mode Delphi is declared.
It should be compatible.

-----

If course I can, I just did.

The mode Delphi is declared.

The mode is entirely irrelevant.

It should be compatible.

We introduced the FieldDef property in TField.
This was a conscious decision.

They chose to use "with", and then this kind of thing can happen at any point. So, they must adapt their code. Don't use "with" if you're not prepared to deal with such issues.

Michael.

Serguei TARASSOV wrote

I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4.

Well, now it doesn't work with FPC 3.0. ;-)

You cannot recommend them to change code.

Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language.

Plus, it's another excellent example of why you shouldn't use WITH. I don't care how many disagree with me, I always thought it a bad language design.

Regards,
- Graeme -

Exactly.

See e.g. the recent changes in TPoint, which necessitated a lot of changes in the LCL, because "with" was used a lot.

Michael.

Okay, okay, I see.

For info, the indicated error is not critical because of its visibility at compile-time.

All other codes inside "with" statement like
x := FieldDef;
will be compiled without errors and should be checked.

Thank you, guys, for a good compatibility support and adding the features to the principal units that break the existing code of "real world programs".

-----

Serguei TARASSOV wrote on Tue, 23 Feb 2016:

Thank you, guys, for a good compatibility support

Come on. The only way this kind of problems can be avoided is by us never adding any new field or property to any class, ever.

It would probably be useful if we added support to the compiler to generate a warning (or even error) in case a with statement hides an existing symbol in scope though.

Jonas

I hope you will send the same mail to embarcadero/Idera. When they added methods to TPoint, they broke have the VCL code ?

To avoid this, we would need to freeze the code as soon as it is released.

Michael.

Jonas Maebe wrote

It would probably be useful if we added support to the compiler to generate a warning (or even error) in case a with statement hides an existing symbol in scope though.

Yes, please. Something like -Wshadow would be very useful.

Henry

Henry Vermaak wrote on Tue, 23 Feb 2016:

That already exists and is enabled by default for local variables and parameter names hiding fields. It even gives errors in FPC and ObjFPC modes, rather than warnings. It's just not (yet) implemented for with-statements (and local variables or fields hiding global variables, but that's a different matter).

Jonas

I have the latest version of Devart pgdac and virtualtable.pas compiles fine.

And the extra typechecks etc. mean that FPC is a bit better than most language implementations at catching things like that.

Mark Morgan Lloyd wrote

And the extra typechecks etc. mean that FPC is a bit better than most language implementations at catching things like that.

Exactly. I prefer getting an error so I can fix my code and know it will work as intended - instead of the compiler silently working around the problem and possibly producing incorrect result (only noticed months down the line).

Regards,
- Graeme -

Michael Van Canneyt wrote

I hope you will send the same mail to embarcadero/Idera. When they added methods to TPoint, they broke have the VCL code ? To avoid this, we would need to freeze the code as soon as it is released.

Compared with Unicode migration, introducing the methods into records is not breaking :)

The code is not frozen but for the core level units the modifications are rare and very risky without vast codebase and testing. DB is a vary mature unit, almost all DACs based on it so 100% compatibility with Delphi does matter.
However, there are some useful methods to extend:
- subclassing (the safest)
- class helpers
- property/method's attributes (need to be introduced at compiler level)
- interfaces (when creating new interface for every extension)

I.e. adding attribute "new" to property/method the compiler will generate the error when conflicting to resolve names in existing code.

There is no perfect way so why the language extension is the safest (remember recent discussion about IfThen pseudo-function).

-----

Adding methods to the TPoint or TRect record is *exactly* like adding a method/property to TField. If you use "with" you might find yourself in a dangerous/problematic situation. That *did* happen with various code after we introduced the new methods to TPoint and TRect.

The code is not frozen but for the core level units the modifications are rare and very risky without vast codebase and testing. DB is a vary mature unit, almost all DACs based on it so 100% compatibility with Delphi does matter.

And the DB code is Delphi compatible. But if you (as in "general you") are using a feature that is *known* to lead to problems if fields and properties are added then that's your own problem. From great power comes great responsibility. We take backwards compatibility very serious, but there has to be a line drawn somewhere.

And to burden everyone else with the need to e.g. include a unit with a helper restricting them from adding their own if they don't derive from the original helper? No thank you. We are no slaves to Delphi.

Regards,
Sven

Serguei TARASSOV wrote

There is no perfect way so why the language extension is the safest (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 := ...

Am 23.02.2016 23:28 schrieb "Mark Morgan Lloyd" <

identifier to WITH to use as an explicit shortcut, i.e. something like

with foo= bar do foo.someField := ...

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.

Regards,
Sven

Sven Barth 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!

WITH should be abolished in my view!

I had to make local variables to shorten down the length of the identifiers and then put the correct variable in front like:

  MS.someproperty := xxx;

Only then was it possible to inspect the values while debugging.

Further: I see every other day in the Embarcadero forum comments by Remy Lebeau where he strongly advices against using WITH. Only goes to show that it plagues Delphi as well.

Join the crusade against WITH!!!

In our previous episode, Mark Morgan Lloyd said:

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

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.

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.

-----

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

etrusco wrote

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

-----

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.

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

Regards,
Sven

Am 24.02.2016 16:44 schrieb "Mark Morgan Lloyd" <

No

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

Pada Rabu, 24 Februari 2016 18:40, Marco van de Voort menulis:

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

"Mr Bee" wrote

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

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.

-----

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 menulis:

"Mr Bee" wrote

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

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

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

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

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.

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.

I don't blame 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.

-----

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.

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

{$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

Serguei TARASSOV wrote

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.

us

version

and

and despite the fact that they started with a fork it's not can't influence precompiled units. Also I wouldn't even remotely want

to maintain such a mess.

Regards,
Sven