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 https://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... On Wed, 9 Nov 2016 at 04:36, jeremy nagel <jeremymna...@gmail.com> wrote: > Just realised this is probably covered by the frozen realms proposal: > https://github.com/FUDCo/proposal-frozen-realms > > Jeremy Nagel > > On Wed, Nov 9, 2016 at 11:33 AM, jeremy nagel <jeremymna...@gmail.com> > wrote: > > Ok I may have been misusing terminology. What I mean is more of a deeply > frozen object along the lines of what happens with > https://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 > > > > On Wed, Nov 9, 2016 at 4:58 AM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > 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 > m...@isiahmeadows.com > > > > On Tue, Nov 8, 2016 at 8:57 AM, Reinis Ivanovs <da...@untu.ms> wrote: > > 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. > > On Tue, Nov 8, 2016 at 7:30 AM, jeremy nagel <jeremymna...@gmail.com> > wrote: > > Hi, > 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*. > > cheers, > Jeremy > > > > _______________________________________________ > > > es-discuss mailing list > > > es-discuss@mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > _______________________________________________ > > > es-discuss mailing list > > > es-discuss@mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
