Immutable const?

Alexander Jones alex at weej.com
Thu Dec 15 09:56:42 UTC 2016


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 <jeremymnagel at 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 <jeremymnagel at 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 <isiahmeadows at 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
> me at isiahmeadows.com
>
>
>
> On Tue, Nov 8, 2016 at 8:57 AM, Reinis Ivanovs <dabas at 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 <jeremymnagel at 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 at mozilla.org
>
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
>
>
> _______________________________________________
>
>
> es-discuss mailing list
>
>
> es-discuss at mozilla.org
>
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> es-discuss mailing list
>
> es-discuss at mozilla.org
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161215/c56773c4/attachment-0001.html>


More information about the es-discuss mailing list