Deconstructor can not be overriden ? Was: Deconstruction patterns

[Brian Goetz]

> The duality you are talking about is this one
>
>    arguments + constructor => instance
>   and
>    instance + deconstructor => arguments
>
> If we add types + liskov substitution principle, we get
>
>    A a = new B(arguments...);
>   and it's dual
>    a instanceof A(arguments...)
>
> As you can see, for the constructors, the arguments are the one of B, so for the deconstructor, it has to be the deconstructor of B, otherwise it only works if the constructor of B do not do any transformation of the arguments when calling the constructor of A.

No, not correct.  If B extends A, when we instantiate `new B(b-args)`, 
we are also _implicitly_ instantiating `new A(a-args)`, because a 
B-constructor must delegate to an A-constructor. Deconstructing with a B 
deconstructor recovers the b-args; deconstructing with an A 
deconstructor recovers the a-args.

In any case, I think you need to back up -- way up -- and figure out 
what your point really is here; this seems to have devolved into 
unhelpful quibbling over terminology.

> Also if we want to support deconstructors on interface, we need a way for implementations of that interface to choose how to implement such deconstructors.

Of course, but the expression of a dtor in an interface will be no 
different than in a class.  (For this to work, the interface has to 
actually be able to implement it, which means the interface needs to 
have methods to access the required state.  This is true for interfaces 
like Map.Entry, which have getKey/getValue methods, but not true for all 
interfaces.)

Is there a specific problem here that you are worried about?