*.empty Idea

C. Scott Ananian ecmascript at cscott.net
Thu Apr 30 16:52:00 UTC 2015

On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller <erights at google.com> wrote:

> On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>> On Feb 23, 2015 6:06 AM, "Andrea Giammarchi" <andrea.giammarchi at gmail.com>
>> wrote:
>> > On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband <ljharb at gmail.com>
>> wrote:
> [...]
>> >>  - We'd definitely want `Map.empty` and `Set.empty` assuming
>> `Object.freeze` actually froze them
>> Object.freeze does not freeze them, as far as I know. It might require
>> method overrides.
> Object.freeze does not freeze their state. A proposal for a way to either
> freeze the state of collections, and/or to create frozen snapshots of
> collections, for future ES would be welcome and appreciated. I encourage
> any such effort to pay attention to Clojure and React.

I ran into this today.

As a strawman proposal:

> Add "If TestIntegrityLevel(M, "frozen") is true, throw a TypeError
exception" between steps 3 and 4 of (Map.prototype.clear), (Map.prototype.delete), (Map.prototype.set),
(Set.prototype.add), (Set.prototype.clear), and

This wouldn't be some fancy all-singing all-dancing collection snapshot,
and would still leave the user responsible for freezing the prototype, etc,
but it would bring Map and Set back into parity with object (that is,
m.get(f) behaves for the most part like o[f]).

Users would still have to special-case Map/Set when they implement their
own deepFreeze() methods, etc, but this ensures that the internal list is
actually protected.  It is (AFAICT) otherwise impossible in ES6 to maintain
object identity when "freezing" an collection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150430/109c89c6/attachment.html>

More information about the es-discuss mailing list