Matcher method name mangling Was: Deconstruction patterns

[Brian Goetz]

>
> That a stronger argument. Not having stable name will cause trouble if 
> the base class and the subclass are compiled separately. Like you, i 
> am not sure of the exact strategy around overriding of matcher 
> methods. During previous discussions, we talked about overridable 
> deconstructors but it seems Brian has now rule them out.
>

The model (as outlined in "Pattern Matching in the Java Object Model") 
hasn't changed.  And it's pretty simple.  There are three kinds of 
"methods": constructors, static methods, and instance methods.  
Constructors are a weird hybrid of static and instance (instance but not 
inherited, etc).

Similarly, there are three kinds of matchers: deconstructors, static 
matchers, and instance matchers.  Again, deconstructors are a weird 
hybrid: instance but not inherited.  (Also, must be total.)

This hasn't changed, the only thing that is different is we're focusing 
on deconstructors now, but we clearly have to come back for the others 
later (and the design has, as stated, taken into account the needs of 
the others as well.)