[fpc-devel] Local variable names and colision with attributes/properties names
Marcos Douglas
md at delfire.net
Thu Sep 27 16:18:48 CEST 2012
On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
>
> On 27 Sep 2012, at 15:51, Marcos Douglas wrote:
>
> What is the advantages to the compiler return the error bellow?
> ERROR: unit1.pas(31,3) Error: Duplicate identifier "FooVar"
>
> Why the compiler do not respect the scope, ie, the local variable
> should have the preference, I'm not right?
>
>
> Yes, but the human brain is very good at confusing such things, and it's
> very easy to accidentally assign something to a local variable instead of to
> a field.
Only Pascal uses that way?
How this works on Java, for example?
> Not? Why I can use a unit name as a property in my class, so? (see
> bellow the "StdCtrls" property name).
>
>
> Because the compiler only checks for identifiers defined in the current
> unit. You also cannot assign anything to a "unit", nor "read" from it, so
> there is generally less ambiguity (it still can exist in case the field is a
> record/class/object and contains fields that have the same name as global
> variables declared in the unit, but that's not exactly common).
And this is normal, ie, use unit names like a property of classe?
> If I use {mode delphi} I can compile... I know. Why not in {mode objfpc}
> too?
>
>
> Because {$mode objfpc} makes different trade-offs compared to {$mode
> delphi}. You can pick the one you like best.
I agree that should be different, but I think this broke the logical syntax.
Another: You always use a common name to represent a local variable,
like Task. If tomorrow you implement a property called Task, you need
to replace all Task local names. You can use the IDE to do this,
ofcourse, but you would replace others identifiers inside of strings,
for example.
Marcos Douglas
More information about the fpc-devel
mailing list