d at domenic.me (2015-05-11T16:55:37.376Z)
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.
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150430/087b018b/attachment-0001.html>