It would also not be compatible with ES6 code. SES will be freezing Map, Set, WeakMap, and WeakSet instances in order to tamper proof their API. I expect many others will as well. Having this freeze then cause a non-mutability in ES7 will break all such ES6 code. This is a non-starter all around.
On Thu, Apr 30, 2015 at 11:18 AM, Mark S. Miller <erig...@google.com> wrote: > 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 <ecmascr...@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 <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 >>> >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
