Design decisions: forward reference, corralling, method keys

[Brian Goetz]

That sounds fine to me!  Dropping it will mean that clients iterating 
the known method keys won't see it (so it falls out of /methods 
listings); if we have lifecycle events, any UI tracking it will get a 
dropped notification and therefore will drop it from view.  So its out 
of the user's face entirely, which is great.

A sketchy API client could still hold the key and ask for state 
information on it; I presume we already have a story for using a key to 
a dropped declaration, and this fits right in?

On 5/20/2015 2:16 PM, Robert Field wrote:
> 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
>>
>