Constant API and Q-type

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Vicente Romero" <vicente.romero at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 1 Novembre 2018 21:21:20
> Objet: Re: Constant API and Q-type

> You can always use ClassDesc.ofDescriptor("QFoo;") to describe a Q-type;
> the only thing that has to change is the descriptor validator code.
> 
> The current behavior of ClassDesc.of(String) produces an L-type; we
> could add ofValue(String) to choose Q-ness, or an asValue() instance
> method to swap L->Q, and isValue() to query L/Q. Everything else built
> on top (e.g., MethodType) should just work.
> 
> What am I missing?

sorry for the delay ...

The same issue as with ASM, those methods are an afterthought that shows a bias to the current view of the world, making the API a little 'of' for the world where reference type and value type both co-exist.

ClassDesc.of() should be renamed to ofJavaName() and takes a second parameter indicating if it's a reference or a value,
ofDescriptor is ok and we should have two other methods ofReferenceInternalName() and ofValueInternalName() that takes an internal names. 

I maybe the only one to have this issue but while testing this API, knowing which methods use a Java name or an internal name was not obvious for me.
Do we really need to have methods that takes a Java name (the dotted variant) ?

Rémi

> 
> 
> 
> On 11/1/2018 4:10 PM, Remi Forax wrote:
>> Hi,
>> did you have a plan for the introduction of the Q-types of valhalla in the
>> constant API ?
>>
>> Introducing Q-types in the ASM API is not that simple, so i suppose you have the
>> same kind of challenges.
>>
> > Rémi