constructor and record/tuple

[pabloalmunia]

Maybe it may seem strange, but any constructor can return a literal object. Sometimes this is interesting in some special classes:

class Point {
  constructor(x, y) {
    return {x, y};
  }
}
const p = new Point(10, 20);

Of course, we cannot return other than a object: https://tc39.es/ecma262/#sec-ecmascript-function-objects-construct-argumentslist-newtarget

As a result, with the current specification of record and tuples we cannot return this kind of elements into a constructor.

class Point {
  constructor(x, y) {
    return #{x, y};
  }
}
const p = new Point(10, 20); // wrong, p is {}

Is it true? Am I right? The idea of immutable object as result of constructor is very atractive for me, but I undestant the special caracteristic of this kind of elements.

[ljharb]

You can return Object(#{x, y}), but it wouldn't be apparent to others that it was a Record or a Tuple.

(You can't make the result of new return an unboxed Symbol or a BigInt either)

[obedm503]

Is there a reason you couldn't return the bare record? If not, could the proposal be amended so that it could?

[ljharb]

@obedm503 yes, that's the way all constructors in JS have worked since time immemorial; it's not something that can change now.

[pabloalmunia]

Yes, this is an almost "prehistoric" behavior that some of us use in our classes, although it is not really recommended.

In other languages there is the possibility of defining classes that return immutable objects and I find it interesting to explore how to add this feature into Javascript.

[pabloalmunia]

Other aproach is to create a subclass from Tuple or Record:

class ExtraTuple extends Tuple {
  constructor(tuple) {
    super(tuple);
  }
  intersection(otherTuple) { /* ... */ }
  union(otherTuple) { /* ... */ }
  difference(otherTuple) { /* ... */ }
  symmetricDifference(otherTuple) { /* ... */ }
  isSubsetOf(otherTuple) { /* ... */ }
  isDisjointFrom(otherTuple) { /* ... */ }
  isSupersetOf(otherTuple) { /* ... */ }
}

const t = new ExtraTuple( #[1, 2, 3] );

assert( t == #[1, 2, 3]);  // true
assert( t === #[1, 2, 3]); // false

Of course, tupla literal and Tupla object are different and only can compare with simple ==, but this approach, although limited, it's more natural.

[littledan]

To clarify for people reading the thread: If a JS constructor returns a primitive, that's taken as a signal that the this value should be returned from the constructor. Since Records and Tuples are primitives, they'd fall into this path.

I'd suggest that people use factory functions (which may be ordinary functions or static methods) to create Records and Tuples, rather than new. In fact, I've heard from several JS programmers that they prefer to avoid using new anyway; Records and Tuples are a great fit for that coding style. Records and Tuples don't really support subclassing and prototype chains (beyond this wrapper usage, which is a bit strange), anyway.

[littledan]

Overall, I don't think it will make sense to create constructors with new that return Records and Tuples, but it would be good to explain in our documentation how to move from using constructors to functions which return Records and Tuples. So, I'm adding the "documentation" label for the next steps.