Deconstructor can not be overriden ? Was: Deconstruction patterns

[forax at univ-mlv.fr]

----- 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 7:02:56 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns

>> Conceptually that violate the principle of encapsulation, you can access to the
>> state of B without using a method of B.
> 
> 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. 
If you do not allow overriding, you do not allow the subclass to have a different semantics than the superclass.

It's maybe clearer with an interface

interface Figure {
  public abstract matcher Figure(int surface);
}

class Rectangle implements Figure {
  int width, height;

  public matcher Rectangle(int surface) {
    surface = width * height;
  } 
}


var figure = new Rectangle(4, 5);
switch(figure) {
  case Figure(int surface) -> System.out.println("Surface is " + surface);
}


> 
>> A de-constructor is also a bundle of accessors, like if you were able to call
>> all the accessors at once.
>> Accessors are overridable for a good reason, otherwise you can leak the internal
>> state.
> 
> Consider A's dtor as a set of final accessors that B cannot override.
> It can provide other accessors in addition.
> 
> If you have a point here, I'm not seeing it?

My point is why "final" !

Rémi