On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth <pascaldra...@googlemail.com> wrote:
> Am 02.03.2012 13:23, schrieb Marcos Douglas:
>
>> On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth<pascaldra...@googlemail.com>
>> wrote:
>>>
>>> On 01.03.2012 21:42, Marcos Douglas wrote:
>>>>
>>>>
>>>> On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth<pascaldra...@googlemail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 01.03.2012 16:34, Marcos Douglas wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 4:29 AM, leledumbo<leledumbo_c...@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
