Deconstructor can not be overriden ? Was: Deconstruction patterns

[Brian Goetz]

>> No, it is an application of LSP; if a B is-a A, I should be able to use
>> a B wherever I currently use an A.  B doesn't necessarily get to
>> interpose itself everywhere; it can't interpose against instanceof
>> testing for A, or casting to A, and it can't override final methods from
>> A.  That's what "extends" means.
> "extends" is 3 things,
> - subtyping (LSP),
> - get all the members of the super class
> - MUST override the methods that have the wrong semantics.
>
> Your design miss the point 3.

When the B author says "B extends A", they are consenting to the 
contract of A, in all its manifest glory.  A may have final methods.  It 
may have deconstructors.  It may have methods with specific contracts.  
It only provides a limited menu of constructors that B can delegate to.  
And B has to ensure that B is substitutible for A in all these ways, or 
it is doing a bad job of extension.

Final methods (and related) are a fact of life; if B cannot be an A 
without overriding these, then it shouldn't extend A.  (This seems so 
obvious I don't even understand why we're talking about it.) Extension 
carries responsibility.

Again, I cannot figure out what your are trying to get at, but it sounds 
to me like you are pointing at a run-of-the-mill interaction but are 
concluding "so the whole design is garbage".  I don't see the line that 
runs from the "this is how it works" to "so it doesn't work", so I'm 
having a hard time understanding what you're getting at.