compiler error when using the same name in class and function.

[mangakissa]

If I have a class like this:

Code: Pascal  [Select][+][-]

1.  TMain = class
2. private
3.   fjaar : integer;
4.   procedure MyFunc;
5. public
6.     property jaar  : integer read fjaar write fjaar;
7. end;
8.  

And I create a procedure / function like this:

Code: Pascal  [Select][+][-]

1. procedure TMain.myfunc;
2. var jaar : integer;
3. begin
4.  ....
5. end;
6.  

Why will the application not compile? It result with this message:

clmain.pas(180,5) Error: Duplicate identifier "jaar"

Delphi doesn't have this problem

Currently I'm using Lazarus 2.02 32 bits / fpc 3.04 / win10.

[Xor-el]

Compile using {$ mode DELPHI} and everything will be stew 

[jamie]

There is also an Switch you can use if you want to stay with ObjFpc mode

Just can't remember it at the moment.

{$MODESWITCH DUPLICATELOCALS} // Allow local variables in class methods to have the same names asproperties of the class.

Book mark that

https://www.freepascal.org/docs-html/prog/progsu105.html

[mangakissa]

Compile using {$ mode DELPHI} and everything will be stew 

That's a workaround not an solution

[lucamar]

Compile using {$ mode DELPHI} and everything will be stew 

That's a workaround not an solution

It is a solution if you want to use constructions which are allowed in that mode (for compatibility) but not in the stricter ObjFPC. If you still want to use ObjFPC but activate some of those features (like this one or, say, nested comments, or assigning callbacks w/out @, etc.) you'll have to use $modeswitch, as jamie said.

My personal recommendation is to use modeswitch unless you are using lots of Delphi-like features or writing dual-compiling code, in which case I'd use the full {$mode Delphi}. Of course, that's just my opinion; YMMV

[Thaddy]

It is indeed not a work around. objpas mode is simply more strict. {$mode delphi} is good advice if you expect it to work like in Delphi, as OP seems to suggest.
Otherwise he will have a whole slew of modeswitches before long....

[mangakissa]

Let me say otherwise: Why is ObjFPC causing this error.
In my opinion a local var has a different pointerview / declaration than a global view. a name has nothing to do with compiling. It's just a reference to a location of address in memory.

It's simple to work with. Just gave the variabele another name, but it shouldn't have.

I love to work with ObjFPC. If I use delphi mode a better can stay to Delphi (my point of view)

[Thaddy]

Let me say otherwise: Why is ObjFPC causing this error.
In my opinion a local var has a different pointerview / declaration than a global view. a name has nothing to do with compiling. It's just a reference to a location of address in memory.

It's simple to work with. Just gave the variabele another name, but it shouldn't have.

I love to work with ObjFPC. If I use delphi mode a better can stay to Delphi (my point of view)

The issue at hand is that it is good programming practice to have unique names, because it can confuse the programmer. It is a helping feature to resolve bugs before they can happen.
As such it is a feature.

Anyway, you can avoid it, - not work around it, it is no work-around  - by using Delphi mode, which would cause that type of errors eventually. Think about scoping errors.

[howardpc]

Let me say otherwise: Why is ObjFPC causing this error.

Mode obfpc raises this error because potential (corner case) ambiguities such as this were one of the reasons for introducing the objfpc mode, part of its raison d'être.
Pascal programmers fall into several camps, one of which sees no need for flagging (or preventing) such potential ambiguities.  Delphi's compiler developers are definitely in this  camp.

Some of those who develop FPC feel differently, and so introduced a stricter mode.
This is not because the compiler itself has any problems at all with potential ambiguities (genuine ambiguity excepted), being thoroughly deterministic, but because sloppy or careless programming and variable naming style can sooner or later trip up both experienced and rookie programmers.

Some of us need our hand held. Others refuse any such aids, and reuse variable names with apparent impunity.

[mangakissa]

That's an answer I can work with