(The headline plays with Edsger Dijkstra's famous article "Go To Statement Considered Harmful") Because the way unit references in the uses clause work in Delphi, you could occasionally get weird and even buggy effects because of changes made in one of the units you use. Note that in general, Delphi handles modularity and code imports much cleaner than most other programming languages. Still there is room for some improvement.
My suggestion is that the Delphi compiler be improved to emit a new Warning for potential name conflicts when the same identifier is imported from two or more units. The goal is to catch unintended changes in semantics after changes have been made to used units.
If I have two units, A & B, both of which export the identifier foo and then in another unit I write:
uses A, B;
Here the reference to foo is without a unit prefix. Currently I would get no warning. My suggestion is to generate a warning, something like this:
"Warning: Potential name conflict: foo declared in unit A and unit B."
To resolve the warning, the programmer would prefix foo with the intended unit name:
This would then generate no warning. Technically, the reference to 'foo' isn't really ambiguous. That's why you shouldn't get a compile error. But like most warnings, this one should be there to catch potential human error or confusion. You have two possible sceniarios:
- The user meant to use A.foo, but because of the unit-ordering he is actually using B.foo.
- Last week, foo was only defined in unit A and the program was compiling working as intended. This week a new foo has been added to B. The program still compiles, but stops working correctly at run-time. This is something that can be really hard to debug and track down - it has happened to me...
#2 is the most dangerous and where the warning would be most useful.