Skip to end of metadata
Go to start of metadata

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

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:

  1. Groovy class names are not "special" in that they can be used directly as variable names;
  2. we do not have a declaration system that can tell us whether a particular name is a declared variable;
  3. we have an import statement that can resolve class name collisions.

This piece of Java needs to go.

– Chris Poirier

Class names

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

  • No labels


  1. Sam

    What about the case where two classes with the same name but different packages are needed?

    Would you suggest something like:

  2. There also an ambiguity between these two lines:

    The current parser resolves this ambiguity in favor of the first line, basically pattern-matching the first three tokens before doing a full parse. This solution will not scale to more complex type names, such as arrays and qualified type names (e.g., Map.Entry). It also prevents use of any sort of package prefix, as Chris points out.

    The difference between the two cases is only detectable by examining the first identifier (println vs. String) and asking whether it has been defined as a type name or a method (or variable) name. I guess this should be done after the parse, and until that point, the AST should look like a method call whose sole parameter is an assignment expression. If during semantic analysis the 'method' turns out to be the statically-typed name of a class, then the thing should be transformed into a declaration.

    If somebody really wants to call a Class object as if it were a method (does this mean something?) then they can use explicit parentheses to form the call. Conversely, I think a special keyword (such as let) should be introduced to force an expression to be interpreted as a declaration:

    My basic take on this (a la design tactics) is to keep the simple things simple (even if it requires the parser to swallow some ambiguity), and provide enough "hooks" for programmers to disambiguate expressions that are misleadingly simple, or simply misleading.