----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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 <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
