> I disagree with that rational because a deconstructor is an instance method, > so you need to do an instanceof first, > said differently P(...) is a deconstruction pattern which is equivalent to > instanceof P p && var values = p.__name_of_the_deconstructor()
At root, I think a lot of your frustration is that you are imagining a different model for what pattern matching means in the language. (I’m sure there are many different possible ways we could add pattern matching to Java.) In fact, I think you are not disagreeing with the rationale, you are disagreeing fundamentally with the model of how deconstruction patterns work in the current model. Deconstruction patterns are declared members, like constructors. The language arranges for them to be invoked as part of core linguistic operations (object instantiation for constructors, pattern matching for deconstructors.) I get that you have another model in mind, but if you want to convince people yours is better, you have to put the model on the table. Believe me, writing this up clearly, consistently, and completely is not a small task, but if you want to move the design, that’s the first step.
