Public/private namespaces in harmony classes proposal

Brendan Eich brendan at mozilla.com
Fri Jul 8 09:52:10 PDT 2011


On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:

> On Fri, Jul 8, 2011 at 12:15 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jul 8, 2011, at 7:43 AM, Juan Ignacio Dopazo wrote:
> 
>> My first thought was: why not just statically replace this.x, with private x, with this[xPrivateName] and forget about accessing private properties of other objects? That would still leave the problem of closures inside methods, though...
> 
> If xPrivateName is a private name object, then there's no reason to "forget about accessing private properties of other objects". Both this[xPrivateName] and other[xPrivateName] work as you would expect.
> 
> /be
> You are very much right. What are the open issues with privates in classes then?

The wiki lists some. Here are a few from memory:

* Syntax to use instead of private(this), private(other). The straw private(foo) syntax is too verbose and it wrongly suggests that a private data record is a distinct object. Are we ready to claim @ as prefix and infix operator (with restriction against LineTerminator on its left)?

* Semantics of private(other).x -- is that a private name access object[xPrivateName] or something else? Without types we don't know what other could be, and it may be a proxy whose handler's traps can observe (something about) the value of x used as a property name.

* Private prototype methods and other properties may be useful, especially methods. One can wrap a closure around the class and put private helpers there, of course, but with private syntax in the proposal, why stop short?

If we do support private prototype properties, then what are the semantics? Private name objects, as recently noted, have their .public counterparts passed as name parameters to proxy traps, so something about private prototype properties may be observable:

class Victim prototypes Proxy { private protoMethod() { privat(super).protoMethod(); } }

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110708/0d42fad2/attachment.html>


More information about the es-discuss mailing list