<p>Am 02.03.2012 16:48 schrieb "Marcos Douglas" <<a href="mailto:md@delfire.net">md@delfire.net</a>>:<br>
><br>
> On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth <<a href="mailto:pascaldragon@googlemail.com">pascaldragon@googlemail.com</a>> wrote:<br>
> > Am 02.03.2012 13:23, schrieb Marcos Douglas:<br>
> ><br>
> >> On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth<<a href="mailto:pascaldragon@googlemail.com">pascaldragon@googlemail.com</a>><br>
> >> wrote:<br>
> >>><br>
> >>> On 01.03.2012 21:42, Marcos Douglas wrote:<br>
> >>>><br>
> >>>><br>
> >>>> On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth<<a href="mailto:pascaldragon@googlemail.com">pascaldragon@googlemail.com</a>><br>
> >>>> wrote:<br>
> >>>>><br>
> >>>>><br>
> >>>>> On 01.03.2012 16:34, Marcos Douglas wrote:<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> On Thu, Mar 1, 2012 at 4:29 AM, leledumbo<<a href="mailto:leledumbo_cool@yahoo.co.id">leledumbo_cool@yahoo.co.id</a>><br>
> >>>>>> wrote:<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> That's different case IMHO (In My Humble Observation), I guess it's<br>
> >>>>>>> something<br>
> >>>>>>> like this:<br>
> >>>>>>><br>
> >>>>>>> {$mode objfpc}<br>
> >>>>>>> type<br>
> >>>>>>> TTestClass = class<br>
> >>>>>>> FTile: Integer;<br>
> >>>>>>> property Tile: Integer read FTile write FTile;<br>
> >>>>>>> procedure Test;<br>
> >>>>>>> end;<br>
> >>>>>>><br>
> >>>>>>> procedure TTestClass.Test;<br>
> >>>>>>> var<br>
> >>>>>>> Tile: Integer;<br>
> >>>>>>> begin<br>
> >>>>>>> end;<br>
> >>>>>>><br>
> >>>>>>> begin<br>
> >>>>>>> end.<br>
> >>>>>>><br>
> >>>>>>> In this case, the local variable has the same name as one of the<br>
> >>>>>>> class<br>
> >>>>>>> properties. This does trigger the "duplicate identifier" error<br>
> >>>>>>> because<br>
> >>>>>>> both<br>
> >>>>>>> have the same scope.<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> Well, for me the local Tile variable should have "preference" because<br>
> >>>>>> the scope is local, not "global for class".<br>
> >>>>>> Would be equal the use of arguments, IMHO, where we can use an<br>
> >>>>>> identifier that already exists in the class.<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> In mode Delphi this is true, but in non-Delphi modes it was decided<br>
> >>>>> that<br>
> >>>>> the<br>
> >>>>> above code is not allowed at all to avoid any disambiguities that might<br>
> >>>>> arise.<br>
> >>>>><br>
> >>>>> Regards,<br>
> >>>>> Sven<br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>> So, I have to invent a prefix or suffix in all local variables to<br>
> >>>> avoid problems if I add a property with same name in the future,<br>
> >>>> right?<br>
> >>>> ex:<br>
> >>>> lTile: Integer<br>
> >>>> Tile1: Integer<br>
> >>>> vTile: Integer<br>
> >>>><br>
> >>>> ...well, I already do that, but I don't think this is correct.<br>
> >>><br>
> >>><br>
> >>><br>
> >>> The compiler will generate an error if you do add a property with the<br>
> >>> same<br>
> >>> name, so you can change the name of the variable in the method on demand.<br>
> >><br>
> >><br>
> >> But if I have many methods with a identifier like Value, I will have<br>
> >> to modify all methods and put something like lValue, Value1, etc.<br>
> ><br>
> ><br>
> > If the methods belong to a class where you introdouced a "Value" field or<br>
> > property, yes, you'll either need to change the variable/parameter of the<br>
> > method or choose a different name for the field/property.<br>
> ><br>
> ><br>
> >>> Also note that this feature is not a recent one. This is part of FPC<br>
> >>> AFAIK<br>
> >>> at least since 2.2.0 (which is the first version I used). So if you<br>
> >>> didn't<br>
> >>> encounter the problem yet, maybe you never will ;)<br>
> >><br>
> >><br>
> >> I had problems. I use FPC 2.6. Because that problems I'm using such<br>
> >> abstract prefix in all local variables.. =|<br>
> ><br>
> ><br>
> > As I said: this feature is older than my first usage of FPC. So you'll have<br>
> > to life with it as we all need to (yes, I would know how to disable it and<br>
> > no, I don't want to). If you want to use ambitious naming then use mode<br>
> > Delphi.<br>
><br>
> OK Sven, I already understood.<br>
><br>
> One more question: why this feature isn't works when used with arguments?<br>
> The arguments could have the same name of a property.</p>
<p>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.</p>
<p>Regards,<br>
Sven<br>
</p>