[Private] yet another alternative to `#`-based syntax

[Igmat]

Disclaimer

My intent here is to show that there are good alternatives to existing private part of this proposal, that were not properly assessed. Probably it happened, because committee has a very limited time and amount of members involved, while such long time for discussion around encapsulation (years or even decades) has lead to loosing clear sight on the problem and possible solutions.

Proposal

It's based on the my proposal in #134 and Symbol.private - I won't repeat them fully here, but I hope that you may visit these links to get more background.
This comment (#147 (comment)) to my initial proposal inspired me to make another one, which dismisses problem with this having more complex semantics than it has now.

Goals:

1. Prevent confusion with private x / this.x pair
2. Symmetry between this.x and obj.x
3. Symmetry between declaration and access syntaxes

Solution

Use Symbol.private with existing lookup mechanism, existing mental model for accessing properties and small syntax sugar to make use of such symbols more ergonomic, by declaring symbol variable in lexical scope of a class.

Syntax 1 (less verbose):

class A {
    // declaring of new private symbols in lexical scope of a class
    symbol somePrivatePropertyName;
    symbol somePrivateMethodName;

    [somePrivatePropertyName] = 'this is private value';
    somePrivatePropertyName= 'this is public value with a `somePrivatePropertyName` property name';

    [somePrivateMethodName]() {
        // it is a private method
    }
    somePrivateMethodName() {
        // it is a public method with `somePrivateMethodName` name
    }
    methodA(obj) {
        this[somePrivateMethodName](); // call private method
        this.somePrivateMethodName(); // call public method
        this[somePrivatePropertyName]; // access private property
        this.somePrivatePropertyName; // access public property

        obj[somePrivateMethodName](); // call private method
        obj.somePrivateMethodName(); // call public method
        obj[somePrivatePropertyName]; // access private property
        obj.somePrivatePropertyName; // access public property
    }
}

const a = new A();
// throws `ReferenceError` since `somePrivatePropertyName` doesn't exist outside of class A
a[somePrivatePropertyName];
// access public property `somePrivatePropertyName` of `a`, as expected
a.somePrivatePropertyName;

Syntax 2 (more generic):

class A {
    // declaring of new private symbols in lexical scope of a class
    const somePrivatePropertyName = Symbol.private();
    const somePrivateMethodName = Symbol.private();

    // everything else is the same as in previous example

    // additional possibility of such syntax
    let numberOfInstanses = 0;

    constructor() {
        numberOfInstanses++;
    }
}

This option is a little bit more verbose, and probably such syntax isn't obvious enough to use for declaring private instance data, but as I shown above it could be used for something else, which is probably make some sense.

Advantages:

1. Doesn't have any problems listed in FAQ
2. No new semantics === easy to learn
3. Full symmetry === prevents accidental missuses
4. Possibility to extend in future, if needed
5. Doesn't use #-sigil, so no risk for breaking community
6. Compatible with TypeScript's private

Disadvantages:

1. Not yet implemented
2. Slogan # is the new _ couldn't be used for education

Conclusion

Since I don't pretend to replace existing proposal with this one right now, because, obviously, my proposal also needs additional assessment, preparing document that reflects changes to ES spec, creating tests, implementing babel-plugin for transpiling, adding support to JS-engines and most importantly wider discussion with community (BTW, existing also needs it), I only hope that this clearly shows the fact that there are still good alternatives, which weren't taken into account.

What is your opinion on that @littledan, @zenparsing, @jridgewell, @ljharb?

P.S.

This syntax also adds a bonus usage scenario:

class A {
    symbol marked;

    markForeignObject(foreignObject) {
        if (foreignObject[marked]) {
            // do something with knowledge that `foreignObject` was already passed to this method
        } else {
            // do something with knowledge that `foreignObject` enters here first time
            foreignObject[marked] = true;
        }
    }
}

And it's only one possible scenario, there could be dozens of them.

[shannon]

Yes please. And we can finally start to use symbols for what everyone I know wanted to use them for in the first place.

P.S. I prefer the first syntax as it's such a minor change to existing syntax.

[hax]

Syntax 2 (more generic):

class A {
    // declaring of new private symbols in lexical scope of a class
    const somePrivatePropertyName = Symbol.private();
    const somePrivateMethodName = Symbol.private();

    // everything else is the same as in previous example

    // additional possibility of such syntax
    let numberOfInstanses = 0;

    constructor() {
        numberOfInstanses++;
    }
}

Syntax 2... You use const/let in class body, they are instance vars with shorthand syntax we discussed in classes 1.1 proposal.

Copy from zenparsing/js-classes-1.1#45 (comment)

class Counter extends HTMLElement {
  const setX = (value) => { x = value; window.requestAnimationFrame(render); };
  const render = () => this.textContent = x.toString();
  const clicked = () => setX(x++);

  let x = 0;

  constructor() {
    super();
    this.onclick = clicked;
  }

  connectedCallback() {
    render();
  }

}

[Igmat]

@hax I thought it could be a confusion between this proposal and classes 1.1, even though Syntax 2 looks like classes 1.1 it has very different meaning and main difference is:

• this proposal adds class scoped variables that used to define private symbol which used to get per-instance private value
• classes 1.1 adds instance scoped private variable

[rdking]

@Igmat Just how useful is the distinction?

Case 1: (Class scoped private symbol used to add instance scoped private property)

• private symbol can be directly shared (desirable)
• property is not an "own property" (required)
• instance is not accessible without the private symbol (required)

Case 2: (private data contained completely within a closure)

• cannot directly leak private data (desired)
• private data is not an own property (required)
• data not accessible from scopes not created by class definition(required)

The kick in the shins here is that for case 1, if by some accident the private symbol is leaked, there's nothing to stop the leak of the private data. Whereas with case 2, if the developer wishes to share some of the private data, the developer must explicitly provide for that. Which is better?

[Igmat]

@rdking in both cases to share private data developer has to explicitly provide access, so probability of unintended leaking is equal for both solutions.
There is no difference between this:

class A {
    symbol somePrivateName;
    leak() {
        return somePrivateName;
   } 
} 

and this:

class A {
    #somePrivate;
    leak() {
        return this.#somePrivate;
   } 
} 

in terms of protecting private data.

And since first allows additional usage scenarios built on that developer is able to share not only private data itself, but also private name, I think that first case is better.

[shannon]

@Igmat it is different because you have leaked the key to the data. Not just the data as in the second case. But I personally think this ok as it's known to be a symbol and key. People shouldn't be returning the key directly and are unlikely to do it by accident. Returning this[somePrivateName] is the equivalent.

[Igmat]

@shannon I didn't mean that those samples do same stuff, I meant that in terms of privacy it doesn't matter what had leaked data or key to data - in both cases encapsulation is broken.

BTW, I realized that leaking of a key seems to be even more unlikely happened than leaking of data.

[rdking]

@Igmat There is a small but important difference. Leaking the data only puts a copy of or reference to the data in public hands. Leaking the key, puts the private property itself in public hands. In the former case, at most, the fields in an object can be changed, but the object itself will remain in the private property. In the latter case, an object in the private property can be completely replaced. If a library keyed something using that object, being able to replace it can break code. On this point, I think my usual opponents would agree with me, being able to leak the actual name of the private field is a worse problem than just leaking the data.

[shannon]

@rdking yes yes, but footguns and flexibility and what not. This to me is a feature and not likely to be done by accident. Developers already understand that symbols are keys and this is a way to explicitly and simply provide access to those private properties.

[Igmat]

@rdking IMO it's rather feature than foot-gun, because there is mostly no chance to unintentionally reveal private symbol.

symbol somePrivate;

this is definitely declaration, more of that - it's self-explaining declaration, and the most important it doesn't interfere with any existing syntax, so it can't be misunderstood like private or #.

Because this class scoped variable has special type - Symbol, it's very unlikely that it could be confused with its value, since last one most probably has different type, so:

---

class A {
    symbol somePrivate;

    leak() {
        return somePrivate;
    }
    notALeak() {
        return this[somePrivate];
    }
}

There is no chance that somebody will implement something like leak(), where actually wants notALeak(), and not only because difference is obvious, but also because first usage of leak() would show that returned result can't be used in place where it was meant to use private data to which it points.

---

class A {
    symbol somePrivate;

    leak() {
        return { somePrivate };
    }
    notALeak() {
        return { somePrivate: this[somePrivate] };
    }
}

This won't be confused for the same reason as previous sample.

---

class A {
    symbol somePrivate;

    leak(cb) {
        cb(somePrivate);
    }
    notALeak() {
        cb(this[somePrivate]);
    }
}

This won't be confused also because cb function most likely expects some value and not a Symbol.

---

class A {
    symbol somePrivate;

    leak() {
        return { [somePrivate]: `anything could be here even private symbol itself` };
    }
}

It's even not a leak, because to access private symbol or its value outer code must have it already.

---

class A {
    symbol somePrivate;

    leak(obj) {
        return obj[somePrivate]= `anything could be here even private symbol itself`;
    }
}

It's not a leak, for same reason as previous sample.

---

I can't imagine how private symbol could leak unintentionally, so it's definitely feature, and not a bug, unless you can provide some example when it happens by an accident.

P.S.

#-private has mostly the same problem if it points to object and not a primitive.

class A {
    #somePrivate = { a: 'some private string' };

    leak() {
        return this.#somePrivate;
    }
}

After calling leak method you can mutate #somePrivate in any way you want.
BTW, since # doesn't support any kind of dynamic access, using one private field (e.g. #state) and storing object with all privates there could become common practice, so last example may be even more common, than we assume now.

[rdking]

@shannon

yes yes, but footguns and flexibility and what not.

Funny. Notice I never claimed that being able to do so was a bad idea. Just capable of a potentially worse problem. In the end, what you're offering is a throwback to proposal-private-fields and part of the foundation of the current proposal. It eventually became the "PrivateName" concept. So while you may have some arguing against you, know it's a viable concept because it's mostly already implemented, but with uglier notation. Btw, symbol privateData just looks too much like a typed declaration. Better to choose a different word.

[Igmat]

@rdking, on one hand it makes sense

Btw, symbol privateData just looks too much like a typed declaration. Better to choose a different word.

on the other hand TS and flow popularized another type anotation:

let a: number;

So I don't think that symbol will be commonly treated as type instead of keyword.
But, obviously, we can change it if there is better candidate.
My thoughts :

1. private - leads to [Private] Metaprogramming vs Security #134 (pros: already reserved keyword, cons: needs additional semantic for this )
2. name/property - aren't self-explanaing enough IMO
3. let/const/any other already used keyword - interfere with existing usage patterns and causes confusion
4. abstract/transient/any other reserved but unused yet keyword - aren't seem to be related enough with proposed semantics

If you have any ideas for better keyword, I would love to take a look on them :)

[shannon]

It might not even be necessary for the symbol to be declared in the class itself. As long as Symbol.private is implemented you can just pair it with the existing public properties proposal for it to be pretty useful. Set/Define debate aside.

const someName = Symbol.private();
class A {
   [someName] = 'private';
  ...
} 

It's easier to use than a weakmap and not incredibly verbose. This is really how I wanted symbols to work in the first place. When I learned that you could just get references to them via getOwnPropertySymbols I was very disappointed.

The symbol/whatever keyword could be added in a follow on as simple sugar. Which would make this just: drop private properties as a class construct and implement private symbols and call it a day.

[shannon]

However, I know people are going to say it needs to be syntax to avoid monkey patching Symbol. So there is that to consider.