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

[Marcos Douglas]

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

Well, happened on the own compiler.  ;-)
IMHO, these collisions happen a lot and because of this many
programmers use prefixes in local variables, see:
lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.).

Marcos Douglas