hg: amber/amber: hooking records to patterns

[Brian Goetz]

An extractor can easily power equals() and hashCode(), and it makes sense to reuse the same one for pattern matching, equals, and hashCode; for toString, you need another argument to provide the labels for the components.  

    Point[x=1, y=2]



> On Apr 7, 2018, at 2:44 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Thinking more about that,
> we should not send the array of components to toString, equals and hashCode but the Extractor (as a condy reference):
> - this will avoid to recreate the array each time (and having to clone it in the bootstrap method of these methods because they can be called directy in Java) because the Extractor is an immutable object.
> - and we do not have to care about direct method handles or not because the extractor is created by the bootstrap method of condy, so the descriptor is not necessary because we can use asType.
> 
> Rémi
> 
> ----- Mail original -----
>> De: "Remi Forax" <forax at univ-mlv.fr>
>> À: "Brian Goetz" <brian.goetz at oracle.com>
>> Cc: "amber-dev" <amber-dev at openjdk.java.net>
>> Envoyé: Vendredi 6 Avril 2018 22:28:17
>> Objet: Re: hg: amber/amber: hooking records to patterns
> 
>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "Vicente Romero" <vicente.romero at oracle.com>, "amber-dev"
>>> <amber-dev at openjdk.java.net>
>>> Envoyé: Vendredi 6 Avril 2018 21:58:52
>>> Objet: Re: hg: amber/amber: hooking records to patterns
>> 
>>> You're forgetting field accessor method handles. You can express Foo::list as a
>>> field getter method handle, but then it has a return type of ArrayList. You'd
>>> have to asType it to express it with a return type of List. Its easy to
>>> represent a direct MH in the CP; its harder (though we can do it now) to
>>> represent an asType MH in the CP.
>> 
>>> Besides, stable interfaces are a good thing. (I could try and infer a method
>>> return type at runtime by analyzing its bytecode, but its better if the method
>>> says "I return List". Same basic deal; the component MHs are implementation.)
>> If you create the MH on the field i agree, but you can create the MH on the
>> getter, so you will have the right type.
>> But, there is maybe no getter.
>> 
>> Thanks for the explanation.
>> 
>> Rémi
>> 
>>> On 4/6/2018 3:52 PM, [ mailto:forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> | forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> ] wrote:
>> 
>>>>> and we have a pattern that yields a binding variable of type `List`.  If
>>>>> the component MH were Foo::list, it would (a) yield the wrong type, and
>>>>> (b) the type might be unstable if the implementation were to change.
>>>>> Having a stable descriptor for what the pattern yields as bindings as
>>>>> separate from the implementation for how to produce those bindings is
>>>>> necessary for stability.
>> 
>>>> All the problems of type you can have are true not only for the extractor but
>>>> also for the getter/component method too,
>>>> so if you already the right type encoded in the component method, you do not
>>>> need to provide the same information as a descriptor.