My ECMAScript 7 wishlist
Mark S. Miller
erights at google.com
Fri Jun 6 06:57:00 PDT 2014
On Fri, Jun 6, 2014 at 5:44 AM, David Bruant <bruant.d at 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 <
> standards at nczconsulting.com> wrote:
> * `Object.deepPreventExtensions()`, `Object.deepSeal()`,
>> `Object.deepFreeze()` - deep versions of `Object.preventExtensions()`, et
> 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
>  https://twitter.com/passy/status/469127322072014849
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss