
A first look at records and tuples in JavaScript - flipchart
https://2ality.com/2020/05/records-tuples-first-look.html
======
combatentropy
Is the hash symbol the best? It already is used within classes to mean
_private_. Syntactically for the machine parser, I assume it will work just
fine for these other things. But semantically for my human brain, it is mildly
incongruous. If for no reason but elegance and developer delight, I ask for a
reconsideration of other punctuation.

~~~
WorldMaker
Seems like a lot of options were/are debated:
[https://github.com/tc39/proposal-record-
tuple/issues/10](https://github.com/tc39/proposal-record-tuple/issues/10)

The benefit to #{}/#[] is that # is not an existing identifier character
(other than private fields) in JS, and _also_ isn't an existing binary
operator. Proposals to TC39 are constrained that they must as much as possible
not "break" existing JS parsing of existing code. That removes a lot of
possible characters because they already have valid parses. It also makes it
tough to introduce new keywords beyond those ES3/ES5 set in stone as reserved,
because they might be identifier names in user applications.

------
pull_my_finger
I've always thought it was interesting to see the parallels of PHPs growth and
JSs. Both seem to add a lot of popular (at the time) features. Neither can
purge old APIs or "break the web".

~~~
ferzul
php purges shitty ideas quite frequently. for instance, i just upgraded some

    
    
        class Foo extends Bar { 
          public Foo() {
            this->Bar();
          }
        }
    

business since it's going away soon.

likewise, magic quotes.

------
amw-zero
This is the number one feature I look for in a language now. It’s hard to
describe why value semantics are useful when thinking about a language as it
exists today, since the language influences what we think is possible. But
having records and tuples like this changes the way you write code.

The biggest example is, you don’t have to think in terms of references
anymore. Again it’s hard to explain how much were forced to think about
references and specific locations that data happens to live at, but that
thinking is pervasive in how we write code (if you’re using a language like
JS, which most popular languages are like).

Value semantics means you can stop thinking about data-as-a-location or data-
as-a-reference and finally start thinking about data-as-data. If two records
have the same values, they are the same. This means you don’t need to know
anything about where data came from, you can construct matching data and say
“are these things equal?” And they will be. This inherently reduces coupling
and complexity.

------
olliej
So from reading this it sounds like what's being asked for essentially
syntactic sugar for Object.freeze(), and the function Record(obj) would be
doing something along the lines of

    
    
      function Record(obj)
        let result = {};
        for (let [key, value] of obj) {
          switch (typeof value) { case "function": case "object": throw ...; }
          result[key] = obj;
        }
        Object.freeze(result);
        return result;
      }
    

Or similar.

Now obviously have typeof return a new type is exciting, and of questionable
value, but having a "only immutable values can be in fields" guarantee could
be useful.

That said, overloading # is not something I think is great, and the semantics
need to be tightened up (fields in prototype chain, etc, what is the prototype
of the resulting record/tuple object).

~~~
amw-zero
You only looked at the conversion of an Object to a Record. That’s really not
the point of this. The point of introducing true records and tuples is to
bring value semantics to JS for compound data types.

It seems like if you create two records with the same nested data, they will
be equal when compared. This may sound small, but if you try out a language
with real value semantics it changes the way you code.

------
ryansobol
The Value of Values with Rich Hickey

[https://youtu.be/-6BsiVyC1kM](https://youtu.be/-6BsiVyC1kM)

------
specialist
Why do records, tuples need new syntax?

~~~
fnordsensei
Because if they went and made immutability the default, they’d break a lot of
existing code that depends on it behaving in a mutable manner.

~~~
specialist
Duh. Thanks. Being tainted by tuples and records from other languages, the
immutable bits didn't register. Sorry.

Reading the proposal (TC39) explains all. [https://github.com/tc39/proposal-
record-tuple](https://github.com/tc39/proposal-record-tuple)

Paraphrasing, if I understand TC39 correctly, an immutable map is a record and
an immutable array is a tuple.

Has a certain elegance. Nicely done. While I'm inclined to like TC39, I'll
chew on it to be sure.

~~~
fnordsensei
Yeah seems so. It’s a shame that they can only be shallowly cast from mutable
to immutable (and will even throw errors if non-primitive values are present).
Seems like quite the limitation.

And yeah, I’m all for immutability as a default, but breaking so pervasive an
existing API is a lot of damage.

