PatternHandle in record
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Oct 10 17:05:41 UTC 2019
----- 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
More information about the amber-spec-experts
mailing list