On 27 Sep 2012, at 16:18, Marcos Douglas wrote:
On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe <jonas.ma...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
