Package qualification of class names
I think we need to eliminate the use of package-qualified class names in general code. We have an import statement that allows the programmer to resolve naming clashes, so we don't actually need to allow qualified names in the code.
The following code appears in o.c.g.tools.DocGenerator:
This demonstrates the use of dotted names that are neither known objects nor package-qualifications. This kind of ambiguity will confuse readers even if doesn't confuse the compiler.
By requiring all package-qualifications to be done in import statements (and possibly on the class declaration line), we eliminate an overload for the dot, and simplify the compiler, without imposing any significant burder on the programmer.
We have a different situation than does Java:
- Groovy class names are not "special" in that they can be used directly as variable names;
- we do not have a declaration system that can tell us whether a particular name is a declared variable;
- we have an import statement that can resolve class name collisions.
This piece of Java needs to go.
– Chris Poirier
At present, we do not allow variables that have names of classes. This has some very counter-intuitive effects, especially given the bug that case-desensitizes class names on some platforms.
I think Class names should take their place in the naming scope as global constants. As such, declared instance and local variables override them where both names are valid. In contexts where only a class name is valid (casts, after "new", etc.), only class names are considered.
– Chris Poirier