The list of required criteria that any private-property proposal must meet.

[trusktr]

Is there a concrete list of technical requirements that anyone proposing a proposal can use for reference? (This would be great to add the FAQ, but I don't think the FAQ itself is that list in the fullest form).

If the list doesn't exist, and will soon be made, then what are the required criteria aside those that relate to disambiguating from other languages.

If JavaScript was suddenly going to be the only language and C++/Java/PHP/etc were all suddenly going to disappear and we were free to implement the privacy on top of existing JavaScript in any way we wished, what criteria would make the private property feature be the best it could be?

---

I'll start making one. The goal is to end with a very concrete list that anyone making any future proposal can use for reference.

1. hard privacy (caveats of source code access aside)
2. leave room for a symmetrical "protected"-like feature to possibly come into existence, even if it doesn't
3. both sigil and full keyword options are available, its up to the author of a class to choose which to use (lint rules can enforce preferences, and tools like prettier can automatically convert code to one form or other)
4. easily use all current language features with private properties (I like to call them properties, you can call them fields though)
   a. both . and [] for accessing the properties regardless of visibility
   b. object spread
   c. destructuring
   d. etc
5. works with static
6. works with methods (including static)
7. private methods (including static) are not wastefully duplicated across instances
8. works with constructor
9. ability to intentionally give outside code access to the private or protected properties, which is useful for implementing concepts like "friends" or similar concepts in other languages.

I'll try to explain with examples. They may have issues, but they serve to get the idea of the criteria across. I'll use !! and private for private, and # and protected for protected in these examples. The syntax ideas here are only a subset of many possible ideas, but the main point is to get the criteria across, not as much to suggest the specific syntax. !! can be replaced with @, and @ can be replaced with ##, etc, if there's any cross-language concerns. But as I've mentioned this criteria should avoid considering outside languages, and focus on the ideal set of criteria for JavaScript as if JavaScript were the last language after the language apocalypse.

After the criteria are established, then external languages can be factored in. Some criteria can be considered for a later proposal, but the initial proposal should be designed so that the possible future criteria can fit into the picture instead of being impossible or very hard to add later.

1) already explained well enough in other issues.

2) no example needed

3)

You may think having both sigil and keyword options is as ugly as some people think having just a sigil is, but that's the least of our concerns to be honest. The functionality is what will win long term.

!! foo = 'private foo'
# foo = 'protected foo'
private bar = 'private bar'
protected bar = 'protected bar'
!! privateMethod1() {}
private privateMethod2() {}
# protectedMethod1() {}
protected protectedMethod2() {}

4a)

this!!.property
this!!['prop' + 'erty']
private.property
private['prop' + 'erty']
this#.property
this#['prop' + 'erty']
protected.property
protected['prop' + 'erty']
this:private.property
this:private['prop' + 'erty']
this:protected.property
this:protected['prop' + 'erty']

4b)

const privateStuffOnly = { ...this!! }
const privateStuffOnly = { ...private }
const protectedStuffOnly = { ...this# }
const protectedStuffOnly = { ...protected }

4c)

const { property } = this!!
const { property } = private
const { property } = this#
const { property } = protected

5)

static !! foo = 123
static private foo = 123
static # foo = 123
protected foo = 123

6)

static !! method() { ... }
static private method() { ... }

7)

// The following methods are NOT duplicated across instances.
// The engine is smart enough to re-use the methods across instances
// They can be private, but still be on the prototype.
!! method() { ... }
private method() { ... }
# method() { ... }
protected method() { ... }

// inside a class:
console.log(this.__proto__!!.method) // works
console.log(this.__proto__#.method) // works
console.log(this.__proto__:private.method) // works
console.log(this.__proto__:protected.method) // works

// outside of a class, all of those are some type of Error

8)

!! constructor() {}
private constructor() {}

# constructor() {}
protected constructor() {}

9)

let fooPriv;

class Foo {
    !! secret = 'private foo'
    
    static shareWithFriends() {
        fooPriv = private // share the visibility helper
    }
}

Foo.shareWithFriends()

export class Bar {
    foo = new Foo
    
    publicMethod() {
        console.log(this.foo:fooPriv.secret)
        // symmetrical with `this.foo:private` and `this.foo:protected` like
        // above point (7)
    }
}

typeof fooPriv === '???' // not a big deal, I'm sure we can come up with something.

// outside code:
import {Bar} from './FooBar'
const b = new Bar
b.publicMethod() // output: "private foo"

[trusktr]

It seems hard to fit proposals like @rdking's or @zenparsing's into all the criteria above; or can we? Maybe the list can be made more generic. Or maybe those proposals are not concerned enough with all the things in the above list (but could be)?

That's what this issue is for, and hoping that a definitive list can be made and added to FAQ.

[trusktr]

Again, please note, I'm not arguing about specific syntax! Obviously there's flaw in my examples, and my examples aren't necessarily consistent (f.e. private.foo vs this:private.foo). So in cases like const protectedStuffOnly = { ...protected }, I'm not looking to debate on whether that should be a syntax error or not, but only showing what functionality it is that we have with regular properties that we'd want with private or protected. Actual syntax can be fleshed out in another thread.

(Sorry, maybe I should not have put so many syntax examples there, but it seemed like an easy way to explain)

[littledan]

Yes, the FAQ contains many of the requirements, though as I've been saying in other threads, it's sort of epistemologically impossible for us to fully prove that we should take these requirements and not others. If there's a requirement that's missing, we can discuss that in particular and work on documenting it, but I don't think a list format would be more clear than the Q/A format than we have now (seeing how many objections we're getting from the other end about why something is a requirement).

If JavaScript was suddenly going to be the only language and C++/Java/PHP/etc were all suddenly going to disappear and we were free to implement the privacy on top of existing JavaScript in any way we wished, what criteria would make the private property feature be the best it could be?

I don't understand where you get the idea that this has been a strong driving factor. Nevertheless, JavaScript will continue to exist within a culture, and be influenced by culture (whether we make decisions that go with or against the grain). Decisions in programming language design are inherently subjective.

It's not productive to continue to reopen issues on topics we are discussing in other threads and post at length. This is not a philosophy debate club; we're trying to work on a project and deliver features to help users. To keep the repository organized and useful, so we can focus on issues like #183, #179 and #176, I'm closing this issue.

[rdking]

@littledan I think you may be under a false impression. This thread seems to have been yet another attempt to get an itemized list of requirements. The FAQ is more of a rationale document that attempts to explain why certain more popular, more conventional approaches were not taken. While that may encompass the elements of the requirements, it is certainly not a clear list that anyone can look at and understand what must and must not be true for a successful private data proposal.

If how I feel is any measure, I doubt there's many if any who feel any further debate will have an effect on the apparently immutable decisions that have been made. We would however, still like to know the points that were considered critical. This would at least help us to understand why other proposals (that to many in the community are simply superior in most ways to the one chosen by TC39) were not considered acceptable.

[trusktr]

@littledan What Ranando describes is what I'm asking for:

what must and must not be true for a successful private data proposal.

@rdking You explained what I wanted very well. Thanks!

Dan, if Ranando were to open a new issue explaining this his way, would you also close it? Is the issue here worthy of being closed?

By closing an issue early, the issue becomes limited to who will see it and thus who will have less input from the outside.

What's your thought on a practice where issues are given some time being being closed? Perhaps a week or two?

---

Ranando, if only you were on the committee (if you wanted to be, that is)! In my humble opinion you'd provide missing balance that the committee needs.