d at domenic.me (2015-05-11T16:55:50.814Z)
this would only be confusing. Object.tamperProof is built on and implies Object.freeze. It is like Object.freeze except that it replaces (some :( ) data properties with accessors in order to work around the override mistake. Object.freeze only operates on properties and the [[Extensible]] bit, nothing more. This is by design. It is the wrong tool for the (very valuable!) job you seek. Again, my apologies for the terrible name.
Hi Scott, this would only be confusing. Object.tamperProof is built on and implies Object.freeze. It is like Object.freeze except that it replaces (some :( ) data properties with accessors in order to work around the override mistake. Object.freeze only operates on properties and the [[Extensible]] bit, nothing more. This is by design. It is the wrong tool for the (very valuable!) job you seek. Again, my apologies for the terrible name. On Thu, Apr 30, 2015 at 11:04 AM, C. Scott Ananian <ecmascript at cscott.net> wrote: > 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. > --scott > > > 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 23.1.3.1 (Map.prototype.clear), >>> 23.1.3.3 (Map.prototype.delete), 23.1.3.9 (Map.prototype.set), 23.2.3.1 >>> (Set.prototype.add), 23.2.3.2 (Set.prototype.clear), and 23.2.3.4 >>> (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 >> > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150430/f33489f9/attachment.html>