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

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


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.

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

Duality does not means having the same characteristics, + and - are dual, but only + is associative.
As explain above, the deconstructor has to be polymorphic otherwise you go not get the right version of the arguments.

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.

regards,
Rémi