Immutable const?
I think final is a bit different from immutable. When you use final
(Java) it means you can only set it once. But when you use immutable it
means every time when you set it, it creates a new object.
Since let (like Haskell) is already reserved by JS. How about def or
directly use immutable?
Actually it isn't useless - limiting variable reassignment significantly increase code readability. Immutability is different use case and it's actually impossible to get immutability when we consider exotic objects and getters/setters.
The string in V8 is internally immutable, so it may be not that hard to add this feature?
This idea sounds like having a version of the const keyword that also
freezes objects, but that's a far cray from what Immutable.js does, which
is about persistent data and collection methods. Freezing also doesn't work
on things that use mutator methods like Map or Set, so it'd be confusing.
JS doesn't have immutable types, which is why Object.freeze simply says
"don't change this object's own properties". Frozen objects make for nice
enumerated types, but JS has no notion of immutability. Additionally, you
have to take into account the internal slots, which freezing objects has no
effect on (it only has an effect with the internal object.[[Get]] and
object.[[Set]] methods).
Isiah Meadows me at isiahmeadows.com
Ok I may have been misusing terminology. What I mean is more of a deeply frozen object along the lines of what happens with www.npmjs.com/package/deep-freeze
The argument for it would be that we've had quite a few bugs where other modules have modified an instance of an object that gets passed around. We now often deep clone parameters at the start of methods to avoid this happening. Would be nicer if deep clone was not required as that has a performance hit.
Edge cases where custom getters or setters could be avoided by throwing an
error if someone attempted to do frozen/final/whateverTheTermWouldBe someComplexObjWithGetters = ...
Jeremy Nagel 0414 885 787
Just realised this is probably covered by the frozen realms proposal: FUDCo/proposal-frozen-realms
Jeremy Nagel
IMO we should unblock anything that stands in the way of ergonomics when using new product type types, other than Object. If I can write code using Immutable.Map as succinctly as I can Object then we're half way there. See esdiscuss.org/topic/map-literal for discussion on generalized map and list literals.
Formalizing things like object spread and destructuring to work on other types would be important, too.
Then, who knows, in ES2019 we might adopt Immutable or something like it into the core library...
was just chatting to colleagues about the utility of const. The fact that it doesn't actually lead to immutable objects or arrays seems to make it a bit toothless and misleading. Are there any proposals to have an immutable version of const? I know you could use ImmutableJS but it would be nice to have this part of the language.
Perhaps the keyword could be final.