Design decisions: forward reference, corralling, method keys

[Robert Field]

On 05/20/15 11:19, Brian Goetz wrote:
> 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.

Yep.

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

We have a story.  Implementation and testing of queries across status is 
a work in progress.

-Robert

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