Hi leledumbo,

(Changing the topic to indicate OT)

I didn't really take time to figure out whether it "should" be happening or not, I just changed the references not to conflict. If you are interested, though, I reproduced it in the screenshot below for you:

https://picasaweb.google.com/lh/photo/qXJYu68KE20oWWM2loKWTtMTjNZETYmyPJy0liipFm0?feat=directlink

Thank you,
Noah Silva

2012/3/1 leledumbo

Hmm. Did you use "Tile" as a field or property of the class TfrmMap already? Then this is expected, because FPC will in non-Delphi modes error if you reuse an identifier, which is already used as a field or property, as a type or local parameter of a method that belongs to the same class.

Regards,
Sven

That's different case IMHO (In My Humble Observation), I guess it's something like this:

{$mode objfpc}
type
  TTestClass = class
    FTile: Integer;
    property Tile: Integer read FTile write FTile;
    procedure Test;
  end;
procedure TTestClass.Test;
var
  Tile: Integer;
begin
end;
begin
end.

In this case, the local variable has the same name as one of the class properties. This does trigger the "duplicate identifier" error because both have the same scope.

Sven,

No, I used it only in TW var section of various methods as a temporary structure. I should note that this compiled in FPC 2.4 fine.

(that said, the source code in question is quite messy...)

-- Noah

Hi leledumbo,

I also tend to Think it's something like that with non-scoped records or something similar. (this is mostly non-oop code, but there are record types with members called "tile" in other units that get pulled in...)

However the compiler specifically names other units as the culprit, so who knows.

Thank you,
Noah silva

Well, for me the local Tile variable should have "preference" because the scope is local, not "global for class".
Would be equal the use of arguments, IMHO, where we can use an identifier that already exists in the class.

Marcos Douglas

In mode Delphi this is true, but in non-Delphi modes it was decided that the above code is not allowed at all to avoid any disambiguities that might arise.

Regards,
Sven

So, I have to invent a prefix or suffix in all local variables to avoid problems if I add a property with same name in the future, right?
ex:
lTile: Integer
Tile1: Integer
vTile: Integer

...well, I already do that, but I don't think this is correct.

Marcos Douglas

The compiler will generate an error if you do add a property with the same name, so you can change the name of the variable in the method on demand.

Also note that this feature is not a recent one. This is part of FPC AFAIK at least since 2.2.0 (which is the first version I used). So if you didn't encounter the problem yet, maybe you never will ;)

Regards,
Sven

However the compiler specifically names other units as the culprit, so who

knows.

Yep, and according to the error message, what if you open the corresponding unit at the position told by the compiler?

Hint: Your form must be a descendant of TForm which perhaps has... guess it ;)

But if I have many methods with a identifier like Value, I will have to modify all methods and put something like lValue, Value1, etc.

Also note that this feature is not a recent one. This is part of FPC AFAIK at least since 2.2.0 (which is the first version I used). So if you didn't encounter the problem yet, maybe you never will ;)

I had problems. I use FPC 2.6. Because that problems I'm using such abstract prefix in all local variables.. =|

Marcos Douglas

If the methods belong to a class where you introdouced a "Value" field or property, yes, you'll either need to change the variable/parameter of the method or choose a different name for the field/property.

As I said: this feature is older than my first usage of FPC. So you'll have to life with it as we all need to (yes, I would know how to disable it and no, I don't want to). If you want to use ambitious naming then use mode Delphi.

Regards,
Sven

But if I have many methods with a identifier like Value, I will have

to modify all methods and put something like lValue, Value1, etc.

Trust me, that's MUCH better than letting the compiler compiles wrong code. i.e. it refers to identifier we don't mean to refer. I've had a lot of this before and the compiler really helps here to avoid hidden error. I usually don't use prefix on identifiers but rename it to something more appropriate (or specific) instead.

The "prefix approach pattern" is used a long time in arguments, e.g., AValue (I prefer aValue).
We do not have case-sensitive so, everything should have a prefix or something to distinguish an indentifier of other (types, classes, interfaces, units, etc);

I'm just following the pattern of language. ;-)

Marcos Douglas

OK Sven, I already understood.

One more question: why this feature isn't works when used with arguments? The arguments could have the same name of a property.

Marcos Douglas

"Marcos Douglas" wrote

On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth

it's

because

might

demand.

or

> property, yes, you'll either need to change the variable/parameter of

the

have

> to life with it as we all need to (yes, I would know how to disable it

and

Normally it should work with arguments as well, but there is a bug if you define a property with an identifier that's used in a method that was defined before the property. In that latter case the check does not work.

Regards,
Sven

To illustrate this a bit:

=== source begin ===

program dupidenttest;
{$mode objfpc}
type
   TTest1 = class
     fFoo: LongInt;
     property Foo: LongInt read fFoo;
     procedure Bar(Foo: LongInt);
   end;
   TTest2 = class
     fFoo: LongInt;
     procedure Bar(Foo: LongInt);
     property Foo: LongInt read fFoo;
   end;
procedure TTest1.Bar(Foo: LongInt);
begin
end;
procedure TTest2.Bar(Foo: LongInt);
begin
end;
begin
end.

=== source end ===

results in the following compiler output:

=== output begin ===

Free Pascal Compiler version 2.6.0 [2011/12/23] for i386 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Linux for i386
Compiling dupidenttest.pas
dupidenttest.pas(9,19) Error: Duplicate identifier "Foo" dupidenttest.pas(31) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: /mnt/data/applications/fpc/2.6.0/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)

=== output end ===

If I comment out TTest1 then the program compiles successfully.

Regards,
Sven

OK.
Well, the safe way is using a prefix/suffix in everything. Thanks for the example.

Marcos Douglas