Security Demands Simplicity (was: Private Slots)

Brendan Eich 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 
weak maps.

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.

/be


More information about the es-discuss mailing list