Regularize the terminology for records, tuples and primitives about proposal-record-tuple HOT 8 CLOSED

I'd suggest that we call this "proposal-records-and-tuples", along the lines of this issue.

from proposal-record-tuple.

Yes, Record and Tuple are big new words we're introducing. So we will be defining these new, strong concepts. I just want to suggest that we minimize the number of words and concepts we introduce. If we want to use "immutable", then maybe we could use that consistently instead, like "ImmutableArray" and "ImmutableObject", though these terms have other issues. I think @BrendanEich made a good suggestion in 2011 to call these records and tuples.

from proposal-record-tuple.

@chicoxyzzy The use of the same term "value types" between these proposals is deliberate. The idea is that the records and tuples in this proposal would somehow form some of the basic precedents to define user-defined value types.

from proposal-record-tuple.

Both “record” and “tuple” are new terms in the JavaScript world. They were chosen somewhat arbitrarily, and don’t convey at all what the nature of this proposal is: Introducing a new kind of data structure to JavaScript that, on the surface, behave like the known collection type structures with the speciality that their contents cannot be changed.

By avoiding the terms “constant” and/or “immutable”, this becomes even more abstract and hard to see.

from proposal-record-tuple.

Both of those terms already have multiple competing meanings in JS, however, so i agree with the OP that these changes would make things clearer.

from proposal-record-tuple.

Indeed, "immutable" could mean any of:

• "like a primitive" (you can set properties on them in sloppy mode, but they're discarded)
• "like a shallow frozen object" (but its [[Prototype]] is mutable)
• "like a deeply frozen object"
• "like a deeply frozen object with internal slots or private fields that can't be modified" (which excludes regexes, promises, maps, sets, or Proxies which may not accurately react like this kind of object intuitively should)
• "like a nonwritable property"
• "like a nonwritable nonconfigurable property"
• "like a const variable"

from proposal-record-tuple.

If we do want to introduce a term, let's choose one of the three (probably "value types"), and define it explicitly before using it.

In that case we have to make sure that "value types" term from this proposal doesn't conflict with Typed Objects' value types

from proposal-record-tuple.

Terminology should be good now

from proposal-record-tuple.