Thoughts what private syntax shoud really be.

[IdkGoodName]

I have read docs of why JavaScript won't use syntax like private something = 123 and access it with this.something, but instead prefix #. Imo, this is how syntax should look:

class A {
    private someVar = 123
    get someVar() {
        return this#someVar
    }
}

Instead of

class A {
    #someVar = 123
    get someVar() {
        return this.#someVar
    }
}

[bakkot]

This FAQ entry is intended to address this and similar ideas.

[IdkGoodName]

I have read FAQ. Apparently, it doesn't talk about syntax I provided. All it showed example of syntax would be

class A {
    #B = 1
    getB() { return this.#B }
}

and

class A {
    private B
    getB() { return private.B }
}

But it said "it will confuse programmers"

It also talked about this#abc without dot, it said it could workout.

[IdkGoodName]

So I think my syntax would be acceptable in JS.

[bakkot]

The FAQ entry I linked addresses all suggestions that private x be used to declare private fields which don't also so use this.x to access them, which includes this suggestion.

[IdkGoodName]

Ok, then point out where it said that declaring private x and accessing it differently than just x is bad?

[bmeck]

@CreatorVilius

declaring private x

https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-arent-declarations-private-x

accessing it differently than just x

https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-not-use-privatex-to-refer-to-a-private-field-of-this-and-privatethatx-to-refer-to-a-private-field-of-another-object .

https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-not-only-allow-accessing-fields-of-this-eg-by-just-having-a-bare-x-refer-to-the-private-field-x

[IdkGoodName]

@bmeck

1. It talks there about both private x and this.x, but not private x and this#x. It talks how accessing privates would influence publics when both would use this.x.
2. I already said that it would be this#privateMethod instead of this.privateMethod, or private.privateMethod. If you think that would still confuse some, then it's same as thinking that people get confused on C++ ::.

[bmeck]

@CreatorVilius it mentions problems with both, combining them does not remove the problems with either one.

[IdkGoodName]

Quote where it mentions. I read FAQ 2 times and never seen that it talked about combining both would be bad.

Ok, let's say it said it's bad combining both. But private x and accessing it with this#x would be same as #x and accessing it with this.#x.

[IdkGoodName]

They can just hold variables same way, but declare them differently and access them differently.

[bmeck]

@CreatorVilius combining both would needs to address the problems of each for that discussion to make sense, which I don't see. You could explain it to me perhaps on how the points of the FAQ are not related when they are combined? I don't see how the points of concern in the FAQ are addressed by your comments.

[IdkGoodName]

Having #x as private field/method and using this.#x would make JS syntax look a little worse. Yes, I pointed out this#x could access private methods, but it was example. this::x could also be private property/method accessor. Maybe private methods could even be accessed using this..x for example, but it wouldn't be a good idea(probably).

how the points of the FAQ are not related when they are combined? FAQ answers how private x and this.x would be bad for JS. It doesn't say anything how private x and this.#x would be bad for JS.

[bmeck]

FAQs are not all encompassing, but both parts of your request are answered in the FAQ as separate problems on their own.

Please explain how the multiple problems, which are stated in the FAQ, do not apply on their own to your combined approach.

Instead of covering each possible combination of choice s the FAQ lays out problems with each choice. Choices with stand-alone problems, such as the 2 in question, remain the same even when combined. The interaction with them somehow fixing the problems is not visible to me. If you can respond to the problems in the FAQ rather than the merits of a particular solution, that might help.

On Jan 11, 2019 2:32 PM, "IdkGoodName" notifications@github.com wrote:

Having #x as private field/method and using this.#x would make JS syntax look a little worse. Yes, I pointed out this#x could access private methods, but it was example. this::x could also be private property/method accessor.

how the points of the FAQ are not related when they are combined? FAQ answers how private x and this.x would be bad for JS. It doesn't say anything how private x and this.#x would be bad for JS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-class-fields/issues/213#issuecomment-453647772, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOUoyNhfKxCo8_DbGvcSr5-qPByK53mks5vCPSegaJpZM4Z8DmW .

[IdkGoodName]

Please explain how the multiple problems, which are stated in the FAQ, do not apply on their own to your combined approach.

I said 100 times, private x is problem, because of it being acessed through this.x. My access thing is different, which would not influence public. - READ THIS 100 TIMES BEFORE COMMENTING SAME THING AGAIN.

I want to you to point out, what will change, when declaring private x instead of #x and using this#x, or this::x, instead of using this.#x.

Problem isn't keyword names such as public, private, protected. Problem is how they thing it should be accessed using this.x when using both private x and public x. Like I said 100 times, my access suggestion is that only privates should be accessed through this#x.

Tell me, what would change from

class A {
    private X = 1
    public X = 2
    getX() {
        return {'public': this.X, 'private': this#X}
    }
}

and

class A {
    #X = 1
    X = 2
    getX() {
        return {'public': this.X, 'private': this.#X}
    }
}

[ljharb]

@CreatorVilius The issue is that saying private x = for declaration means that access must include the private keyword (because the declaration includes it). Your suggestion does not have that consistency between declaration and access.

[bakkot]

The issue is that saying private x = for declaration means that access must include the private keyword

(I would say rather that it access must be this.x, like it is in TypeScript or Java or etc.)

[littledan]

@CreatorVilius I hope these explanations have been helpful, and sorry if we sound a bit abrupt: We've looked through a bunch of different syntax alternatives, and thought about various possible combinations, before settling on the syntax of this current proposal. This feels like a mix of previous proposals, with similar problems to other proposals, as explained above.

[jhpratt]

@littledan Not related to this specific issue, but in the FAQ it's noted that the private.x syntax could prevent engine optimization. How would this vary from any other object? The private fields are statically knowable, so surely it could be represented as a struct?

[littledan]

@jhpratt I don't know how that could work if we use private(obj) (within a class) to get an object that has all of the private fields in it. Presumably, that object would have identity.