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
> 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> <
> 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.
> On Thu, Apr 30, 2015 at 9:52 AM, C. Scott Ananian <ecmascript at cscott.net>
>> On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller <erights at google.com>
>>> On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows <isiahmeadows at gmail.com>
>>>> 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>
>>>> >> - 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 188.8.131.52 (Map.prototype.clear),
>> 184.108.40.206 (Map.prototype.delete), 220.127.116.11 (Map.prototype.set), 18.104.22.168
>> (Set.prototype.add), 22.214.171.124 (Set.prototype.clear), and 126.96.36.199
>> 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...
More information about the es-discuss