[fpc-pascal] Re: Duplicate Identifier

[Marcos Douglas]

On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth <pascaldragon at googlemail.com> wrote:
> Am 02.03.2012 13:23, schrieb Marcos Douglas:
>
>> On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth<pascaldragon at googlemail.com>
>>  wrote:
>>>
>>> On 01.03.2012 21:42, Marcos Douglas wrote:
>>>>
>>>>
>>>> On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth<pascaldragon at googlemail.com>
>>>>  wrote:
>>>>>
>>>>>
>>>>> On 01.03.2012 16:34, Marcos Douglas wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 4:29 AM, leledumbo<leledumbo_cool at yahoo.co.id>
>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>
>>>
>>>
>>> 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.
>>
>>
>> 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.
>
>
> 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.
>
>
>>> 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..  =|
>
>
> 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.

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