Deconstructor can not be overriden ? Was: Deconstruction patterns

forax at univ-mlv.fr forax at univ-mlv.fr
Tue Mar 7 20:23:04 UTC 2023


----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Tuesday, March 7, 2023 8:42:37 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns

>>> 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.
> 
...
> 
> 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 ?

regards,
Rémi


More information about the amber-spec-experts mailing list