3 ms·

one thing that it's missing in JS to fully harness the benefits of immutability is some kind of equality semantics where two identical objects are treated the s

• no_wizard 11mo ago
  They were going to do this with Records and Tuples but that got scrapped for reasons I’m not entirely clear on. It appears a small proposal along these lines has appeared in then wake of that called Composites[0]. It’s a less ambitious version certainly. [0]: https://github.com/tc39/proposal-composites https://github.com/tc39/proposal-composites
  • lhnz 11mo ago
    Records and Tuples were scrapped, but as this is JavaScript, there is a user-land implementation available here: https://github.com/seanmorris/libtuple https://github.com/seanmorris/libtuple
    • jazzypants 11mo ago
      Userland implementations are never as performant as native implementations. That's the whole point of trying to add immutability to the standard.
      • agos 11mo ago
        even when performance might not be an issue or an objective, there are other concerns about an user land implementation: lack of syntax is a bummer, and lack of support in the ecosystem is the other giant one - for example, can I use this as props for a React component?
  • agos 11mo ago
    yes, I'm aware of composites (and of the sad fate of Records and Tuples) and I'm hopeful they will improve things. One thing that I'm not getting from the spec is the behavior of the equality semantics in case a Date (or a Temporal object) is part of the object. In other words, what is the result of Composite.equal(Composite({a: new Date(2025, 10, 19)}, Composite({a: new Date(2025, 10, 19)})? What is the result of Composite.equal(Composite({a: Temporal.PlainDate(2025, 10, 19)}, Composite({a: PlainDate(2025, 10, 19)})?