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.
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. 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. > On Oct 10, 2019, at 6:37 AM, Remi Forax <fo...@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
