Public/private namespaces in harmony classes proposal

Gavin Barraclough 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.

cheers,
G.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110707/50a8da14/attachment.html>


More information about the es-discuss mailing list