Design decisions: forward reference, corralling, method keys

[Brian Goetz]

> That's fine.  We will allow forward reference only on methods, classes,
> and variables without initializers.
> Or, would it be more consistent to allow only on methods and classes?
> If, in the field, we hear clamorous user objection we can rethink this.

I prefer the former; essentially, allowing forward refs on all "pure" 
declarations.

> Maybe Jon's idea that the user entered type names should be the key is
> going to yield the least surprising results.

That's what I (thought I) was suggesting too.

Where the anomaly comes is:

void foo(Baz b) { }
  -> key k1

void foo(com.bar.Baz b) { }  // redeclaration of above foo!
  -> new key k2, *but which ultimately describes same member as k1*

That is, the second foo replaces the first (its signature is the same), 
but there are now two keys describing the same thing.  (Admittedly a 
corner case.)

> With that choice, all the above would be one key.
> There could still be ambiguity errors:
>
> void w(Set x) { }
> void w(java.util.Set x) { }
> w(new HashSet())
>
> But in that case, which seems far less likely to occur, the key
> descriptors of the methods would distinct:
>
> |  Error:
> |  reference to w is ambiguous
> |    both method w(Set) in  and method w(java.util.Set) in  match
>
> So it would be clear what to drop.
>
> -Robert
>