value type hygiene

[Remi Forax]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "daniel smith" <daniel.smith at oracle.com>, "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 10 Mai 2018 18:27:00
> Objet: Re: value type hygiene

> On 10/05/18 00:46, Dan Smith wrote:
>> (To be clear about my preferred alternative: we introduce Q types as first-class
>> types (applicable to value classes only), update the descriptor syntax, assert
>> QFoo <: LFoo, and ask compilers to use Qs when they want to guarantee
>> non-nullability and allow flattenability. Compilers generate bridge methods
>> (and bridge fields?) where needed/if desired.)
> Yes!
> 
> To be clear, it seems like we've been before - I recall a rainy Friday
> spent at a whiteboard in Dublin a couple of years ago on this one. As
> you point out there's a tension here: on the one hand, 'just' using
> L-types (at least in method signatures) give you a path, when it comes
> to type-specialization, not to touch method bodies.
> 
> On the other hand, if L means "maybe L, maybe Q", clients have no way to
> disambiguate L-code from Q-code - meaning that the
> Q-accepting-method-in-L-disguise will always have to be prepared for
> handling things coming from outside its clean almost-Q-but-not-quite bubble.
> 
> Also, with my bridge hat on (having written many of them) I have to note
> that, while Remi is right in saying that having separate descriptors for
> L and Q is *almost* (added by me) equally expressive as having just L
> with a side-channel (e.g. attribute which lists which Ls are Qs), that
> move restricts us a lot in terms of bridg-y move we can make - as, at
> the VM level there's only one true signature (the L one) and you can't
> write a bridge (from where? to whom?). Unless we want to start emit
> bridges that have signature that is identical to the bridged thing - but
> this seems to violate so many constraints that I don't think it's even
> worth mentioning (in fact pretend I didn't write it :-)).

You can try to bridge inside the implementation, i.e. you have one method, so one signature, with an indy in it (indy let you access to the class metadata and the runtime view) that can decide to which implementations (implemented as side static methods) you want to delegate. I've already done this in case you have one method in Java that match multiple methods in a dynamic language. (I did not write too)

> 
> 
> Maurizio

Rémi