Matcher method name mangling Was: Deconstruction patterns

[Brian Goetz]

>> We use the ["Symbolic Freedom"]() encoding of the erasure of the matcher
>> descriptor as the mangled disambiguator, which is exactly as stable as
>> any other
>> method descriptor derived from source declarations.
> I do not think you need mangling, you need different name but matcher$0, matcher$1, etc or something similar with a counter should be enough.

This might be OK if the pattern train ended permanently at 
deconstructors (and even then, it is iffy.)

Recall from "Pattern Matching in the Java Object model" that instance 
patterns are a thing, and instance patterns can be overridden.  (This is 
how, for example, `Map` would specify that `get` is really a pattern.)  
While deconstructors are not inherited and therefore can't be 
overridden, instance patterns can, and you want the translated method 
name in the superclass and subclass to be the same, so that ordinary 
virtual dispatch does the right thing.

Further, even in the absence of inheritance, you want to be able to 
stably select the name of a pattern method in a client at compile time, 
with confidence that, absent a source-incompatible change in the 
declaration, it will select the right method at run time.  Using a 
counter has all the same brittleness as inner class names; if you 
rearrange a source file, Foo$1 will mean something else.

The mangling proposed here is selected to be stable with respect to 
recompilation, reordering members in a source file, adding and removing 
other members, etc, for both selection and overriding.

> The Matcher attribute contains enough information to do the linking both at compile time and at runtime.
>
> The idea is that in the bytecode, you can derive the MethodType from the invokeVirtual (or invokedynamic) and then ask the VM the method that has a Matcher attribute that matches that MethodType.
> So the exact name of the matcher method should not be present in the bytecode of a switch that uses a deconstructor, only the corresponding MethodType should be present.
>
> Mangling method names appear in stack trace, if we can have "light mangling", i.e. a counter likes with lambdas, instead of a C++ like mangling, i think it's a win.

This sounds like "let's invent a new kind of VM dispatch so method names 
can be slightly less ugly."  This doesn't seem like a win to me?