On Fri, Jun 6, 2014 at 5:44 AM, David Bruant <bruan...@gmail.com> wrote:
> Le 06/06/2014 01:08, Rick Waldron a écrit : > > On Thu, Jun 5, 2014 at 6:42 PM, Nicholas C. Zakas < > standa...@nczconsulting.com> wrote: > > * `Object.deepPreventExtensions()`, `Object.deepSeal()`, >> `Object.deepFreeze()` - deep versions of `Object.preventExtensions()`, et >> al. >> > > Does "deep" mean that a Map instance's [[MapData]] is frozen if > deepFreeze is called on a ? eg. what happens here: > > var m = Object.deepFreeze(new Map()); > m.set(1, 1); > > I think the intention behind Object.freeze was to make objects immutable > (at a shallow level), so maybe the semantics of Map.prototype.set (and all > modifying operations, of Map&co) should be changed to read the > [[IsExtensible]] and throw if false is returned. Given Maps are already in > the wild, this decision might need to be taken quickly. > The main intention of Object.freeze is to make objects tamper proof. To ensure that their API surface is only according to the provider, not to the clients, and thereby prevent client A from corrupting the API seen by client B. This is why Object.freeze has no effect on non-configurable accessor properties -- their writable-property-like behavior is fully in control of the abstraction provider. Of course, it does also cause some further immutability beyond that initial purpose, and so there become valid purposes too. The API surface of an array consists of data properties, so freezing an array turns it into a shallowly immutable array. Typed Arrays refuse to be frozen as of ES6. Post ES6, perhaps we will enable them to be frozen, resulting in their indexed properties being immutable, since these are presented as data properties. Were we allow these to be frozen, they would also become un-neuterable, which means they would be passed over postMessage by sharing of the underlying data, rather than by ownership transfer of that data, which is exactly what you want once the data is immutable. By contrast, a Map's state is more like the private instance variable state of a closure or a post-ES6 class. Object.freeze of a Map should not alter the mutability of this state for the same reason it does not alter the state captured by a closure or a future class instance. > or should an Object.makeImmutable be introduced? (it would be freeze + > make all internal [[*Data]] objects immutable) > We do need something like that. But it's a bit tricky. A client of an object should not be able to attack it by preemptively deep-freezing it against its wishes. > > > > >> * `Object.preventUndeclaredGet()` - change an object's behavior to throw >> an error if you try to read from a property that doesn't exist (instead of >> returning `undefine`). >> > (I already know that Nicholas and I disagree on the topic, but sharing > for debating). > Once again, perhaps it is something that the provider of an object could determine, but it shouldn't be something up to an object's clients. But like you observe below, we can already do this with a proxy, so let's not introduce a second mechanism without a compelling reason. And the proxy solution wraps the initial object, rather than changing its behavior in place, so it does not enable one client to corrupt the behavior seen by other clients. > > > This can be achieved with Proxy right, or is that too cumbersome? > > Code-readability-wise, wrapping in a proxy is as cumbersome as a call to > Object.preventUndeclaredGet I guess. > > This sort of concerns are only development-time concerns and I believe the > runtime shouldn't be bothered with these (I'm aware it already is in > various web). For instance, the TypeScript compiler is capable today of > catching this error. Given that we have free, cross-platform and fairly > easy to use tools, do we need assistance from the runtime? > Yes. Object.freeze is a runtime production protection mechanism, because attacks that are only prevented during development don't matter very much ;). > > David > > [1] https://twitter.com/passy/status/469127322072014849 > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
