[fpc-devel] Local variable names and colision with attributes/properties names

[Jonas Maebe]

On 27 Sep 2012, at 16:18, Marcos Douglas wrote:

> On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe <jonas.maebe at elis.ugent.be 
> > wrote:
>>
>> 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?

Java doesn't put any restrictions on things like that. And it's not  
"Pascal" that works this way, it's FPC-specific. At least Ada most  
likely has something similar though.

>> 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?

I don't know how common that is, but as mentioned: it is much less  
likely to result in errors than having local variables with the same  
name as properties/fields/methods.

>> 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.

It's a trade-off: it has both good and bad aspects. We believe the  
good ones outweigh the bad ones. It was introduced after a bug was  
discovered in the compiler itself that was caused by such a problem.

> 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.

Yes, it's always possible. In practice, I haven't seen this happen a  
single time in the 10+ years that the compiler has had this feature.  
That doesn't mean that it's impossible, but it's another factor in the  
"good to have" versus "causes more harm than good" equation.


Jonas