*.empty Idea

C. Scott Ananian ecmascript at cscott.net
Thu Apr 30 18:04:46 UTC 2015

Mark: I also agree that `Object.freeze` is flawed, and I welcome a proper
proposal for `Object.tamperProof` or what have you.  But `Object.freeze`
works just well enough in the short term that people can build useful
mechanisms on top of it.

My proposal just makes `Map`/`Set` behave consistently with `Object` with
respect to `Object.freeze` (preserving the consistency between object
fields and the behavior of `Map`).  I think that consistency is preferable
to the current situation, even though (as I said) I welcome a proper
mechanism for immutability in the future.

Said a different way: one day we will have `Object.tamperProof` and it will
be wonderful.  But we will always be stuck with `Object.freeze` as well,
because it's been released into the while.  Let's at least try to make
`Object.freeze` a little more consistent, and not let future features
prevent us from improving what we have now.

On Thu, Apr 30, 2015 at 1:17 PM, Mark S. Miller <erights at google.com> wrote:

> This must *not* be hung off of Object.freeze. Object.freeze is about
> tamper proofing an object's API, not about making its internal state
> immutable. I regret the term "freeze" for this purpose as it repeatedly
> suggests this confusion. OTOH, because of the override mistake,
> Object.freeze is not directly usable as a good tamper proofing operation,
> so in this sense it was fortuitously good that it did not use up the name
> tamperProof.
> Deep immutability is a crucial concept deserving of good support for many
> reasons including security patterns. Deep immutability must of course
> include encapsulated state captured by lexical closures, and it must do so
> without violating the security properties that this very encapsulation
> guarantees. The Auditors of E <
> http://www.erights.org/elang/kernel/auditors/>, <
> http://wiki.erights.org/wiki/Guard-based_auditing> and Joe-E <
> http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf> <
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-244.html>
> provided solutions to this dilemma in their respective languages. E and
> Joe-E also support shallower forms of immutability that are specific to
> collections -- that are distinct from API tamper proofing but that do not
> extend to considering the mutability of the contents of the collections.
> I welcome proposals that would make sense for JavaScript.
> On Thu, Apr 30, 2015 at 9:52 AM, C. Scott Ananian <ecmascript at cscott.net>
> wrote:
>> 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
>> (Set.prototype.delete).
>> 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.
>>  --scott
> --
>     Cheers,
>     --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150430/c406e06f/attachment-0001.html>

More information about the es-discuss mailing list