My ECMAScript 7 wishlist
bruant.d at gmail.com
Fri Jun 6 07:37:44 PDT 2014
Le 06/06/2014 15:57, Mark S. Miller a écrit :
> By contrast, a Map's state is more like the private instance variable
> state of a closure or a post-ES6 class.
The capabilities to arbitrarily modify Maps (set/delete on all keys,
with any values) will be expected by any ES6-compliant code to be
globally available, so a Map's state cannot reasonably be considered
This differs from the state of a closure where its access is strictly
moderated by the public API giving access to it and to the fact that
this API is not provided globally (unlike Map.prototype).
> 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.
I'd argue the Map state is very much like regular objects (for which you
can't deny [[Set]], [[Delete]], etc.), not closure's state.
In an ES6 world, denying access to the global Map.prototype.* would
break legitimate code, so that's not really an option confiners like
Caja could provide.
> 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.
I don't see the difference with shallow-freezing?
It's currently not possible to defend against shallow-freezing (it will
be possible via wrapping in a proxy).
>> 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 ;).
Just to clarify, I agree that Object.freeze was necessary in ES5 (have
we had proxies, it might have been harder to justify?), because there
was no good alternative to protect an object against the parties it was
But the concern Nicholas raises doesn't seem to have this property.
Reading a property that doesn't exist doesn't carry a security risk,
does it? Object.preventUndeclaredGet doesn't really protect against
anything like ES5 methods did.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss