Derived record creation and Data Oriented programming

Remi Forax forax at univ-mlv.fr
Tue Apr 30 13:22:31 UTC 2024


Hello,
they have been several messages on amber-dev about the compatibility of the derived record creation.

I think part of the issue reported is that with the proposed syntax, the call to the desconstructor and the canonical constructor is implicit.

Let's take an example

  record Point(int x, int y) {}

  var point = new Point(2, 3);


In fact,
  var point2 = point with { x = y; };

is a shortcut for:

  var point2 = point with {
    Point(int x, int y) = this;  // i.e. int x = this.x(); int y = this.y();
    x = y;
    yield new Point(x, y);
  };

One problem with the current syntax is that because the call to the [de]constructors is implicit. I think we shoud allow users to write the implicit calls if they want.

I wonder if
- we should not allow yield to be used so the compiler adds yield automatically only if there is no yield ?
- we should in the future when deconstructors are introduced, allow users to call a deconstructor explicitly and only provide one if not explicitly written ?

Being able to write the calls explicitly is important because it's a way to detect if the record has been modified without the proper constructor/destructor has been written to be backward compatible (Like in a switch, a record pattern detects when a record component is added while a type pattern does not).

Being able to call a the deconstructor explicitly also have the advantage to avoid to declare a variable/calls the accessor if not needed.
By example
  var point2 = point with {
    Point(_, var y) = this;
    x = y;
  };

regards,
Rémi


More information about the amber-spec-observers mailing list