Latest Thinking

[Howard Lovatt]

Yes you can hide a type name, but you can do that at present -
therefore no change. My reading of JLS 6.5 is that what I am proposing
is fine, it will simply resolve to the variable if their is ambiguity.
What I was saying was that if you have hidden the type name then you
can qualify it. What I didn't add is that you might also have hidden
the qualifier, but hiding the qualifier is already a problem and
therefore no different than currently (and the problem, hiding the
type name and the qualifier simultaneously, to the best of my
knowledge, doesn't occur in practice). Here is a current example of
hiding the qualifier and using a qualifier name in the same position
as a variable name (the two print lines are identical, the first
refers to a type and the second a variable):

public class Bar {
  static class integer {
    static String toString(int i) { return java.lang.Integer.toString(i + 1); }
  }

  static class Lang { static integer Integer = new integer(); }

  static class Java { static Lang lang = new Lang(); }

  public static void main(String... notUsed) throws Throwable {
    System.out.println("java.lang.Integer.toString(1) = " +
java.lang.Integer.toString(1));
    Java java = new Java();
    System.out.println("java.lang.Integer.toString(1) = " +
java.lang.Integer.toString(1));
  }
}

Which prints:

java.lang.Integer.toString(1) = 1
java.lang.Integer.toString(1) = 2


  -- Howard.

PS Yes a single namespace would be nice (Newspeak's solution is
particularly good).

John Rose john.r.rose at oracle.com Thu Jun 24 00:28:38 PDT 2010 wrote:
> On Jun 23, 2010, at 8:27 PM, Howard Lovatt wrote:
>
>> Can't you just qualify the name
>
> The same observation applies to 'java' in 'java.lang.String' as to unqualified 'String'.  The point is that identifiers have context-sensitive meanings in Java.
>
> Expression contexts have different resolution rules from type contexts, which means type names aren't compatible with expression contexts.
>
> The JLS documents this fully in the section on names, and is worth reading carefully when pondering language puzzles like this.
>
> It is true that previously-undefined names could in principle be given new meanings without breaking old programs, but this is a dangerous design tactic
> given wildcard imports and inheritance, which can bring names into scope suddenly due to non-local API changes.
>
> Java will never be a single-namespace language.  Try Scala or Scheme!
>
> -- John