How to implement a record de-constructor ?

[Remi Forax]

While a de-constructor is not strictly needed until we want to serialize a record or do Pattern matching on it,
i think it can be useful to share what i think about implementing a de-constructor.

Technically a de-constructor is the inverse operation of a constructor (hence the name), instead of being a function (int, int) -> Point, it's a function Point -> (int, int).

In Java, it's something like this:
  record Point(int x, int y) {
    public (int, int) <deconstructor>() {
      return (x, y);
    }
  }

The issue is that there is no tuple in Java, so writing a de-constructor now is not easy.
Valhalla is currently adding value type, and a tuple is a kind of anonymous value type, so while at some point in the future, Java will have tuples, delaying the introduction of records until we have tuples is not something we should do.

So we have two ways to deal with the implementation of a de-constructor:
1/ internally, toString/equals or hashCode implementation of a record are already using a form of de-constructor as an array of method handles, one by fields, so a de-constructor is seen an an array of getters. We can add a method in the Reflection API, by example, on java.lang.Class that returns this array of method handles. In term of implementation, one can use a constant dynamic to create an immutable list of method handles and just need a way to poke this constant pool constant by example by storing the constant pool index in a class attribute.
2/ we can code the deconstructor in a way that let the calling code of the de-constructor to choose which kind of object it want to return, like this:
  record Point(int x, int y) {
    public Object <deconstructor>(MethodHandle mh, Object o) {
      return mh.invokeExact(o, x, y);
    }
  }
java.lang.Object being the root for all types in Java, value types or not, this will abstract the construction of a value type in the future.
Sending a method handle as also the advantage that instead of creating a tuple, it can also be used to by example the the values inside a ByteBuffer (or any output stream), but for that we need to pass the ByteBuffer as a parameter hence the parameter o.
This design as also the advantage of being compatible with the extractor of Scala, or any API that box the field values into one or more objects.

regards,
Rémi