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 <erig...@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 <ecmascr...@cscott.net> > wrote: > >> On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller <erig...@google.com> >> wrote: >> >>> On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows <isiahmead...@gmail.com> >>> wrote: >>>> >>>> On Feb 23, 2015 6:06 AM, "Andrea Giammarchi" < >>>> andrea.giammar...@gmail.com> wrote: >>>> >>>> > On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband <ljh...@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 >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
