Design decisions: forward reference, corralling, method keys

[Robert Field]

Here is another option that gets most of the same results in this 
obscure case without duplicates, aliasing or other strange new bells and 
whistles --

    The overwritten key (foo(Baz) in the example below) is dropped.

-Robert

On 05/19/15 13:40, Robert Field wrote:
>
> 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
>