Design decisions: forward reference, corralling, method keys

[Robert Field]

On 05/19/15 12:33, Brian Goetz wrote:
>
>
>> 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.)

Currently, the Key is both the external and internal key.  That creates 
clean semantics.  But also the possibility of the ambiguity error I 
described (below).
What you are describing has some internal magic that know that two keys 
are the same (thus the internal key is different than the external), and 
the complexity comes when that mapping can change over time.

As a first (or final) step we would make method key type parameters be 
the user entered type parameters.

>
>> 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
>>

-Robert