Classes: suggestions for improvement

Brendan Eich brendan at
Sun Jun 12 18:17:55 PDT 2011

On Jun 12, 2011, at 4:54 PM, Juan Ignacio Dopazo wrote:

> If I understand correctly the reason for needing private(this).x is because the private names proposal allows having a private name with the same name as a common property.

Whether private in class uses private name objects or some other unobservably-different implementation is not specified. It may not be observable even with reflection we can agree to put in the language any time soon.

Allen points out that a self-hosted debugger with VM-like stratification would want to peek at privates (as it would also at closure innards). In such scenarios, private name objects may be attractive, since they can yield to reflection (via .public, or without that substitution in a privileged "VM host" or "outer ring" trusted environment such as a debugger).

Closures for private vars have notable costs, discussed here recently, and so are not suitable in the foreseeable future. But to your point below, closures may be too closed if we are talking about the constructor.

> Also IIRC , this is a result of putting instance properties in the constructor. Because of that the private name lives in the scope of the constructor and not in the scope of the class. So would this be correct?
> class Monster {
>     private jump() {
>         console.log('jump!');
>     }
>     constructor() {
>         this.jump();
>     }
> }

Not yet specified, but possible. Here an unobservable closure around the class (the power constructor pattern, IINM) could be used to hold the prototype-available, once per class evaluation, private bindings. Or perhaps private names on the prototype object could be used, but freeze would have to skip them.

I'm not sure classes should grow to have private class or prototype variables in Mark stripped things down to help get classes in. The one reason I come back to them: private methods for common subroutining are frequent in practice. So YAGNI doesn't work. One can always closure- or module-wrap by hand; that's the counterargument.


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

More information about the es-discuss mailing list