The problem is not at callee site, as you said you have deconstructor binding 
like you have constructor parameter, the problem is at callsite, when you have 
a Type Pattern, a type pattern does not declare a type that can be used at 
compile time but a class that is used at runtime (to do the instanceof).
So the problem is not how to declare several deconstructors, it's how to select 
the right one without type information.

Overload selection works largely the same as it does with constructors, just 
with some of of the “arrows reversed”.

But I think you’re extrapolating from deconstructors too much, which are a very 
constrained kind of declared pattern.  A pattern combines an applicability test 
(does the target match the pattern), zero or more conditional extractions 
(operations performed on the target only when it is known to match), and 
creation of variables to receive the extracted data.  For a deconstruction 
pattern, the applicability test is highly constrained — it is a class-based 
instanceof test, and the language knows it.  If its of the right type, the 
deconstruction must succeed — it is *total* on that type.  But this is a very 
special case (and a  very useful case, which is why we are doing them first.)

Consider a more complex situation, such as querying whether a regex matches a 
string, and if so, extracting the groups.  Here, we can use whatever state we 
like as our match criteria; we are not constrained to work only with runtime 
classes.  More importantly, the code to determine the match and extract the 
parameters is completed; if we exposed this as a boolean-returning method 
(“does it match”), we’d have to do all the work over again when we go to 
extract the groups (its like containsKey and get in Map.)  This is why the 
current regex implementation returns a stateful matcher object.

Class-based matching is just the easy case.

nope, because if we have a type pattern / record pattern we have no type 
information.
If named pattern method allows overloading, we will have the same issue, there 
is not enough type information at callsite.

I’m not following this argument.  Can you try to write out some end-to-end 
examples where you say what you are trying to accomplish?

By simpler model, i mean we do not have to mirror all the method call quirks as 
patterns, only the ones that make sense from a "data oriented design" POV.

OK, but all your arguments are “against” — you just keep saying “we’re doing it 
wrong, w can make it simpler.”  You haven’t outline *how* it can be simpler, or 
what problems you are actually worried about.  Which makes them pretty hard to 
understand, or respond to.



Reply via email to