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: Wednesday, March 8, 2023 5:35:37 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns

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

The problem with this semantics is that this is worst that with accessors, because at least you can override an accessor.

It means that once a deconstructor is provided, subclasses can not change it.

If know that a lot of features introduced since Java 5 does not support inheritance but maybe you should be more public about the fact that inheritance is a second class citizen in Java. Personally, i'm fine with that but i want to be sure it's not an unintended side effect.

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

A specific implementation of Map.Entry not being able to fix the default implementation.

By example, if my Map is thread-safe and implemented with two arrays and a lock, i will want the deconstructor to be able to synchronize on the lock, something the default implementation will not do. 

regards,
Rémi