PatternHandle in record

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 10 Octobre 2019 17:57:46
> Objet: Re: PatternHandle in record

> The answers to these questions are beyond the scope of the record discussion,
> and while I’m happy to discuss them at some point, I would like to focus on
> getting records out the door right now, so I ask your forbearance in not diving
> down the pattern translation rabbit hole right now.

i agree, let's release the records first.

> 
> The places where records touch pattern matching will likely be stripped out for
> the first preview of records; they are there right now as a means of validating
> how all the pieces fit together.  Because deconstruction patterns won’t be
> ready for the first preview, we’ll likely back these pieces out.

yes 

> 
> But, these are not _descriptions_ of the pattern — they are the _implementation_
> of the pattern.  And remember, patterns will go far deeper than mere
> deconstruction patterns (which yes, could be special-cased at the use site for
> records); they are executable class members, and can be virtual.  So there
> needs to be support in the class file for linking to patterns; the strategy
> that is currently on the table is that patterns are represented in the class
> file by methods that yield a Pattern constant, that static patterns are
> represented by static methods, and instance patterns are represented by
> instance methods.  And because a pattern with the same name can be overloaded
> with multiple signatures, we need a stable name to invoke that captures not
> only the name but also the descriptor.

yes, patterns may be more general and virtual but i was talking about the one that is currently generated inside a record classfile, and that one only describes statically the record, something i think is not necessary given you can always ask at runtime is a class is a record or not.

so it seems, we can agree that an automatically generated pattern is not useful, at least the first version of the records.

Rémi

> 
> 
> 
>> On Oct 10, 2019, at 6:37 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi all,
>> ASM doesn't like too much weird method names,
>> exactly the ASMifier, that take a binary class and generate the Java code that
>> will create the same binary class, doesn't work well with the method named
>> "\%pattern\%RecordSubType\%(ILjava\|lang\|String\?)".
>> 
>> I have two questions:
>> - why do we need a description of a pattern inside a record class given that the
>> Record attribute already provides that description (that is accessible using
>> Class.getRecordComponents()) ?
>>  A record is already able to describe itself, that's its purpose, why do we need
>>  another way of describing it ?
>> - why the method that return a PatternHandle is using a mangled name like this ?
>>  Given that the constant dynamic also use the same encoding ??
>> 
>> Rémi
>> 
>> public static java.lang.runtime.PatternHandle
>> \%pattern\%RecordSubType\%(ILjava\|lang\|String\?)();
>>    descriptor: ()Ljava/lang/runtime/PatternHandle;
>>    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
>>    Code:
>>      stack=1, locals=0, args_size=0
>>         0: ldc           #29                 // Dynamic
>>         #1:"\\%pattern\\%RecordSubType\\%(ILjava\\|lang\\|String\\?)":Ljava/lang/runtime/PatternHandle;
>>         2: areturn
>>      LineNumberTable:
> >        line 9: 0