Security Demands Simplicity (was: Private Slots)
brendan at mozilla.com
Sat Jan 19 18:02:42 PST 2013
Allen Wirfs-Brock wrote:
> Who's to say that a symbol keyed object
You must mean "property" not "object".
> can't be added to an object after Object.freeze has been applied to it. Before we can say that we have to define the semantics of symbol keyed objects and possibly extend Object.freeze/isFrozen to accommodate those new semantics. What's the guidance for doing so? What abstract concept of "frozen" do we to apply to the semantics of new language features?
This is not an abstract question. Implementors may want
Object.preventExtensions to put an object in a state such that
optimizations can rely on it never growing new properties. Frozen
objects could even be promoted by a copying GC into read-only memory,
with the OS virtualized hardware MMU providing greater integrity.
More to the point, programmers may wish a frozen object o having
properties p and q, and null or frozen prototype chain of known
properties, never to grow property r. Whereas using weakmaps explicitly,
of course one can call r.set(o, v) to set r's value to v.
If we are talking about private syntax only in classes, this may not
matter. Either private symbols or weak maps suffice. But proxies can
tell, and prototype-based inheritance works for private symbols but not
So even if we allow a frozen object to grow new private-symbol-keyed
properties not in that object at the time it was frozen (or let's say
the time Object.preventExtensions or its internal form was invoked),
private symbols and weak maps are distinguishable. If they weren't, we
surely would have no need for one or the other.
More information about the es-discuss