Deconstructor can not be overriden ? Was: Deconstruction patterns

[Brian Goetz]

>> Again, I cannot figure out what your are trying to get at, ...
> My question is why a deconstructor should be always final ? Why a de-constructor can not be polymorphic ? Why it's not up to the user to choose if a de-constructor should be final or not ?
>

It's a fair question, but I think framing this as a "restriction" is 
misleading.  It emerges as a consequence of duality with constructors, 
and constructors have particular characteristics (such as not being 
inherited.)

If you want to declare a polymorphic, overridable, inheritable matcher, 
you can -- that's "instance matchers" (just as you can do so with 
instance methods.)  The "Object Model" doc outlines the distinction 
between constructor-like, static-like, and instance-like matchers.

It's not a "restriction" that B cannot "override" `x instanceof A` or 
`(A) x`; it's simply what these things mean. And since every B is an A, 
and that means construction flowed through an A constructor, it is 
reasonable to ask A-specific questions of a B, without necessarily 
giving B the chance to interpose.

Could we define the model differently, where all matchers are partial, 
or all matchers are instance methods?  Yes, of course we could define an 
alternate language with those characteristics. Would it be better?  
Maybe, depending on your metric of better. Does the existence of 
alternate models mean the model proposed here is wrong?  No, of course not.

The central organizing principle here is that aggregation and 
destructuring are duals.  This means deconstructors are best understood 
as co-constructors, and static and instance patterns are co-factories.  
By defining them as duals to the corresponding members that are already 
in the language, we guide users towards the right mental model, and set 
ourselves up for defining aggregation-deconstruction pairs with the 
desired properties -- specifically, that they form embedding-projection 
pairs.  This allows us to not only use pattern matching directly, but 
also to build things like withers on top of it.

Could we define deconstructors but make them gratutiously different from 
constructors?  Of course we could, but that's probably not helpful to 
users.

I think what's going on here is that you have a vague, alternate mental 
model of what patterns are supposed to be, and you're comparing to that 
and so any different feels like a "restriction", but unless you can put 
your model on the table, we can't compare the pros and cons.