*.empty Idea

Mark S. Miller erights at google.com
Thu Apr 30 18:22:26 UTC 2015

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 <erights at 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 <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 (Map.prototype.clear),
>>>> (Map.prototype.delete), (Map.prototype.set),
>>>> (Set.prototype.add), (Set.prototype.clear), and
>>>> (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/8394b41e/attachment-0001.html>

More information about the es-discuss mailing list