Developer experience of the syntax and semantics of this proposal

[mbrowne]

This new issue is intended as a continuation of the recent discussion in #100. (The only reason for a new thread is that the original has become very, very long, which among other things makes it less approachable to anyone not already participating in the discussion.)

VERY IMPORTANT NOTE: Anyone who would like to comment here should first read the PRIVATE SYNTAX FAQ. This will save everyone time. Thank you.

[nabil1337]

Hi,
I've been programming with JS for about six years now. I never intended to influence the standard, because most new things were indeed quite useful and made sense. But I have a feeling that the language is now being bloated with too many and partially weird things, just like the # char to declare private fields.

The strengths of JS are - among others - that it's simple and easy to learn for devs coming from C/C++, Java or PHP.

So, we have syntax and classes like in some of these languages. Why not just do something like:

class MyClass {
    myVar = 3; // public field
    public otherVar = 4; // also public field
    private yetAnotherVar = 5; // private field

    protected myMethod () {
        // do things here...
    }
}

As you can see, adding access modifiers is optional in this example, the default one being public.
Public fields will simply be properties on the instance object that can be accessed normally from outside the class, whereas attempting to access private/protected from outside will throw an error e. g.:

const myObject = new MyClass();

myObject.myVar; // returns 3
myObject.yetAnotherVar // throws Error

And while I'm at it, athough this is OT:

function myFunc (String name, Number age, cityOrCode) {
    // name is definitely a String
    // age is definitely a Number
    // cityOrCode can be any type
}

let myVar = 3; // normal variable, any type
let String otherVar = 'some string'; // can only be assigned a string type

My point is: JS should be simple and not have unexpected, weird syntax. Development of the language should focus on making a developers life easier and allowing noobs to quickly understand code. In my opinion, it's better to not have a feature, than to add a weird or complicated one (Object.assign, # for private, ...)

[ljharb]

It would be unexpected and weird if "private" things were publicly visible properties that threw on access, exposing their existence.

[nabil1337]

It would be unexpected and weird if "private" things were publicly visible properties that threw on access, exposing their existence.

Good point. Maybe make private and protected fields not enumerable. Though I think this would only be an issue in those cases, where you attempt to add random properties to instance objects - which is bad style anyway, e. g.:

let myInstance = new MyClass();
myInstance.someRandomProp = 3; // bad style, unless someRandomProp is a known public field.

[ljharb]

Whether it's a bad style or not isn't the point - it's a core feature of javascript that objects are mutable unless otherwise made immutable, and privacy isn't related to mutability.

[nabil1337]

Whether it's a bad style or not isn't the point - it's a core feature of javascript that objects are mutable unless otherwise made immutable, and privacy isn't related to mutability.

I would expect privacy to be related to mutability, just as it is the case in other languages. If the standard doesn't yet allow this to be the case, shouldn't it be adjusted first? In other words: If the standard limits you from implementing fields the easy way, why would you implement them in a hard to grasp way instead of adjusting the standard first, before attempting to implement fields?

[ljharb]

JS is constrained by backwards compatibility, so no, that's not something that can ever be changed.

[mbrowne]

@nabil1337 It sounds like you might not have seen or read the FAQ about the private fields syntax. Actually this prompted me to add a disclaimer to my first post here encouraging everyone to read that FAQ as a prerequisite for commenting on this thread. This is not intended to be overly strict or unwelcoming but simply to make the discussions here more productive. This is especially important given that the private field syntax in particular has been discussed very extensively especially in the past couple years, and the syntax you suggested has already been suggested by many others and comes with some very significant tradeoffs that have been discussed many times.

Of course, as you can see by reading through comments in #100, the syntax is still quite controversial even among those who are aware of the tradeoffs. But it's important to realize that syntax like this:

class MyClass {
    private myPrivateField = 1; // private field

    someMethod() {
       console.log(this.myPrivateField);
    }
}

...would actually make it impossible to have fields that are 100% private. This relates to another past discussion that you might want to familiarize yourself with, regarding the desire for "hard private" and the tradeoffs between hard private and soft private: #136. And just to counterbalance what @ljharb said, in many other languages you can always access private properties via reflection, so private doesn't have to mean 100% hard private, but the committee has landed on hard private being an important requirement especially for library authors (for more on that as well as counterarguments, see #136 as well as earlier discussions in #100 and other threads).

After years of careful deliberation, this class fields proposal is already in stage 3 which means it's highly unlikely that it will be changing much. The main reason for continued discussion is that there are still some alternative proposals that some community members are interested in, primarily these three:

• https://github.com/zenparsing/js-classes-1.1
• https://github.com/rdking/proposal-class-members (a modified/expanded version of classes 1.1)
• https://github.com/zenparsing/proposal-private-symbols

As @littledan (a committee member) has communicated, the TC39 committee has reaffirmed consensus on the class fields proposal multiple times, so keep in mind that these alternative proposals are unlikely to succeed... but since many people still have concerns with the current proposal, there is still interest in discussing them, improving them, and advocating for them in the hope that the committee might hold off on a final decision and reconsider other options one more time.

(Side-note: Personally I am more interested in advocating some smaller adjustments to the current proposal rather than rejecting it completely, and I believe the use of a prefix like # is the best possible option for private fields given the constraints. But the above summary is not a reflection of my opinion but rather my attempt at a realistic description of the situation right now, so as not to give anyone unrealistic expectations.)

[nabil1337]

@mbrowne Thank you for explaining! Sorry I didn't notice the FAQ.

I have some remarks:

The FAQ states:

Having a private field named x must not prevent there from being a public field named x, so accessing a private field can't just be a normal lookup.

It explains this as follows:

If private fields conflicted with public fields, it would break encapsulation; see below.

Futher:

Library authors have found that their users will start to depend on any exposed part of their interface, even undocumented parts.

The simplest solution would be to just throw an error when trying to access these special fields, as I proposed.
It doesn't really matter if someone knows that there is a private field foo, as long as they are unable to get it's contents. This is probably also what #136 meant.

My approach:

• more similar to other languages, faster to learn
• not propagating the anti pattern of having duplicate field names (imagine forgetting the '#' or adding it when not needed)
• not having to deal with this['#x']
• allowing for protected
• no weird characters involved

I know, this has apparently been discussed for years. But as a normal dev, you don't really get to know all these things too quickly. And please consider the largely negative feedback from the recent discussion. Shouldn't the people who actually use the language be able to decide if they want this proposal? Thanks for your time.

[ljharb]

Yes, it absolutely matters, because it means adding, renaming, or removing private fields becomes observable and thus part of the public api. Its contents are irrelevant, its mere existence is information that must not be obtainable.

[bakkot]

In addition to @ljharb's comment, it would also be really annoying from an ergonomics point of view if a private field on a base class prevented a similarly named public field or method on a subclass. Among other things, it would mean that adding a private field would always be a potentially breaking change.

Shouldn't the people who actually use the language be able to decide if they want this proposal?

A great many people involved in this discussion actually use the language quite heavily both personally and professionally, myself included.

[kaizhu256]

operationally, how many of you would actually enjoy maintaining web-projects with polymorphic-classes with subclassed-properties having the same names as [unobservable] private-fields?

this feels like a low-level hammer for low-level general-purpose programming things encountered in java/c++, not a high-level glue-language like javascript used by most of us primarily for baton-passing serialized JSON-objects around (with async static-functions).

[trotyl]

operationally, how many of you would actually enjoy maintaining web-projects with polymorphic-classes with subclassed-properties having the same names as [unobservable] private-fields?

@kaizhu256 The real problem is, one would never know what private fields are used in base class as they're not part of your project, and they're also not documented as not being part of the public API.

So that whenever trying to extend an external class, your derived class would break weirdly. Even it doesn't break now (when you writes them), when the base class add a new private field suddenly your class is broken.

[kaizhu256]

@trotyl, the problem is deeper than that. i feel the whole class-based approach to solving async, UX-workflow problems commonly encountered in javascript is flawed.

class-methods are ok for blocking-code design-patterns in java/c++, where adding new features simply means inserting new blocking code between-the-lines of existing blocking code.

class-methods are not ok in async UX-programming where commonly added features like autocomplete, autovalidation, file-upload-progress, etc... often involve rewriting the entire ux-workflow (and any io-based class-methods with it). most of these tasks are more elegantly solved with callback-based static-functions.

[mbrowne]

@ljharb

Yes, it absolutely matters, because it means adding, renaming, or removing private fields becomes observable and thus part of the public api

It's a bit of a stretch to say it's part of the "public api" if that weren't the author's intention at all and they indicated it with private, but this is indeed an important consideration for anyone writing classes that will primarily be consumed by others. I found the code example in this comment by @bakkot quite helpful for understanding this issue.

Another significant issue is that without a prefix, the interpreter wouldn't have an immediate way to distinguish between private and public at the location in the code where a field is being accessed. For a compiled language this wouldn't be a big issue, but since JS is an interpreted language, it would make all property/field access more expensive (at least at class evaluation time). @nabil1337 that's why your suggestion of just throwing an error if someone attempts to incorrectly access a private field is not as great of a solution as it seems, because the interpreter would have to check for all possible base classes and prototype modifications on every private field declaration to make sure there isn't already a public field with that name, and some of the accesses as well (at least the dynamic ones).

For these reasons, even the alternative proposals that community members here are still seriously considering include dedicated syntax for accessing private fields. There is also one other option that I think is very much worth considering, which is keeping # but adding the keyword private to the declarations (e.g. class MyClass { private #x = 1; ... }). That would make the syntax more consistent and easier to explain in the future if other access levels besides public and private were ever added.

BTW @nabil1337, I'm not sure if you're already aware of this, but this['#x'] is not a valid way of accessing a private field in this proposal. That would access a public property named '#x'. This is an unfortunate but necessary consequence of the rest of this proposal given the need for backward compatibility.