[fpc-pascal] Re: Duplicate Identifier

[Sven Barth]

Am 02.03.2012 16:48 schrieb "Marcos Douglas" <md at delfire.net>:
>
> 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20120302/f3ba2bc6/attachment.html>