Public/private namespaces in harmony classes proposal

Juan Ignacio Dopazo dopazo.juan at
Fri Jul 8 10:20:26 PDT 2011

On Fri, Jul 8, 2011 at 1:52 PM, Brendan Eich <brendan at> wrote:

> On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:
> 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)?

Why do privates need special syntax? Isn't the point to just use them with

> * 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(); } }

Isn't that only an issue of "protected" vs "private"?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list