Public/private namespaces in harmony classes proposal

Brendan Eich brendan at mozilla.com
Thu Jul 7 23:15:50 PDT 2011


On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:

> Ah, I see.  It's a fair point, but isn't this already a hazard that the language faces?

Not with private names.


> Suppose I have two objects, extensible instance X with private instance property 'foo', and extensible object Y upon which I have defined a property 'foo' using Object.defineProperty, setting writable=false.  If a client of Y tries to extend if with a public 'foo' property, then this would fail (throwing a TypeError in strict mode code).  Would it not be acceptable for the attempted assignment to the private property of X to fail in a similar fashion?

No, that leaks the fact that there's a private-named object (if you also enumerate public names and do not find such a name; or enumerate property descriptors, etc.).


>  It seems that it is already the case that if a client wishes to associate data with a given object under any arbitrary name, then the only truly safe way to do so is through an external mapping such as a weak map / ephemeron table?

No, private names are in ES.next:

http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects


> Might it be reasonable to make private properties be regular properties on the object, with a new 'private' attribute, similar to the existing writable/configurable attributes?  From the perspective of code outside of the associated class, an instance's private property would be non-readable, non-writable and non-configurable (likely also non-enumerable?), with any attempt to get, set, or delete the property failing in a similar manner to an existing writable/configurable attribute violation.  It would be great to hear your thoughts on this.

See above -- private means you can't probe, let alone collide, for the private name from outside of the abstraction. Private name objects prove much more than a single-bit 'private' attribute -- they allow private, protected, friend, shared-secret, and public-but-guarnateed-unique names.

/be



More information about the es-discuss mailing list