Minimalist (why) classes ?

Axel Rauschmayer axel at
Sun Nov 13 05:54:35 PST 2011

> Except I'm not sure the @private could be made to work without creating confusing semantics around it, so object literals would still be one step behind.
> As far as I understand "@private_stuff" would desugar into a name object only available in scope of the object literal.

The basic idea of private names is that you don't use names directly, but store them in a variable and use that variable whenever you need to refer to something:

var _name = "MyClass_private_a3cfb";
function MyClass(name) {
    this[_name] = name;

The actual private names are very similar to _name above, but they are not strings, they are special objects that are never listed anywhere (one step beyond non-enumerable, if you will).

Thus, the challenge is clear: You have to introduce variables such as _name in a manner that makes them accessible wherever you need them.

> var o = {
>   @private_stuff: bar;
>   method1() { }
> }
> var o = (function () {
>   var private_stuff = name.create();  
>   var ret = {
>     method1() { }
>   }
>   ret[private_stuff] = bar;
> })();
> I personally don't find that confusing.

The latest ideas are about requiring a private section where you declare private_stuff.

var obj = {
    private { private_stuff }
    @private_stuff: bar,
    method1() {
        return this. at private_stuff;

It does desugar like you mention above. If you use constructor functions without any tricks, then scope is an issue:

var private_stuff =  name.create(); // it would be nice to have support for a private section here
function MyClass(stuff) {
    this. at private_stuff = stuff; // same as this[private_stuff]
MyClass.prototype.method1 = function () {
    return this. at private_stuff; // same as this[private_stuff]

Dr. Axel Rauschmayer
axel at


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

More information about the es-discuss mailing list