hg: amber/amber: hooking records to patterns

[forax at univ-mlv.fr]

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