Public/private namespaces in harmony classes proposal
barraclough at apple.com
Thu Jul 7 23:07:28 PDT 2011
On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote:
> On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough <barraclough at apple.com> wrote:
> Hi Mark,
> In the harmony classes proposal, http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in understanding the following issue:
> One or two namespaces for public properties and private instance variables [RESOLVED two, Mark’s argument]
> Do you remember if this argument was made in email, and if so would anyone happen to know where to look to find this (I've tried a little googling to no avail!), I'd be interested in understanding the rationale behind this decision.
> I don't think it was made in before in email. Here goes:
> For non-const classes, their instances are extensible by default. Even if you disagree with this default, I think we generally agree that there should at least be an option to make extensible instances.
> Say public and private share one namespace. Say extensible instance X has private instance property 'foo'. Say a client of X tries to extend it with a public 'foo' property. What happens?
Ah, I see. It's a fair point, but isn't this already a hazard that the language faces?
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? 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?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss