On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote: > > On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough <barraclo...@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.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
