{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/100","repository_url":"https://api.github.com/repos/tc39/proposal-class-fields","labels_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/100/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/100/comments","events_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/100/events","html_url":"https://github.com/tc39/proposal-class-fields/issues/100","id":320925205,"node_id":"MDU6SXNzdWUzMjA5MjUyMDU=","number":100,"title":"A summary of feedback regarding the # sigil prefix","user":{"login":"glen-84","id":261509,"node_id":"MDQ6VXNlcjI2MTUwOQ==","avatar_url":"https://avatars0.githubusercontent.com/u/261509?v=4","gravatar_id":"","url":"https://api.github.com/users/glen-84","html_url":"https://github.com/glen-84","followers_url":"https://api.github.com/users/glen-84/followers","following_url":"https://api.github.com/users/glen-84/following{/other_user}","gists_url":"https://api.github.com/users/glen-84/gists{/gist_id}","starred_url":"https://api.github.com/users/glen-84/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/glen-84/subscriptions","organizations_url":"https://api.github.com/users/glen-84/orgs","repos_url":"https://api.github.com/users/glen-84/repos","events_url":"https://api.github.com/users/glen-84/events{/privacy}","received_events_url":"https://api.github.com/users/glen-84/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":364,"created_at":"2018-05-07T19:25:26Z","updated_at":"2018-11-19T12:13:22Z","closed_at":"2018-10-10T14:16:03Z","author_association":"NONE","body":"<table>\r\n    <thead>\r\n        <tr>\r\n            <th>Issue/comment</th>\r\n            <th>👍</th>\r\n            <th>👎</th>\r\n            <th>🎉</th>\r\n            <th>❤️</th>\r\n        </tr>\r\n    </thead>\r\n    <tbody>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-methods/issues/10\">Stop this proposal</a></td>\r\n            <td>196</td>\r\n            <td>31</td>\r\n            <td>20</td>\r\n            <td>45</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-fields/issues/14\">Why not use the \"private\" keyword, like Java or C#?</a></td>\r\n            <td>132</td>\r\n            <td>7</td>\r\n            <td>12</td>\r\n            <td>5</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216042553\">Why not use the \"private\" keyword, like Java or C#?</a> 💬</td>\r\n            <td>144</td>\r\n            <td>0</td>\r\n            <td>16</td>\r\n            <td>9</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216304000\">Why not use the \"private\" keyword, like Java or C#?</a> 💬</td>\r\n            <td>51</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/6\">Private Properties Syntax</a></td>\r\n            <td>33</td>\r\n            <td>4</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-methods/issues/28\">Yet another approach to a more JS-like syntax</a></td>\r\n            <td>32</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>41</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-methods/issues/20\">New, more JS-like syntax</a></td>\r\n            <td>32</td>\r\n            <td>4</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/77\">Please do not use \"#\"</a></td>\r\n            <td>32</td>\r\n            <td>0</td>\r\n            <td>1</td>\r\n            <td>1</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/56\">Proposal: keyword to replace `#` sigil</a></td>\r\n            <td>18</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>1</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-methods/issues/8\">Why not use private keyword instead of #?</a></td>\r\n            <td>16</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>1</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/zenparsing/js-classes-1.1/issues/40\">Explore a more JS-like syntax</a></td>\r\n            <td>7</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/99\">The '#' looks awful, please change it</a></td>\r\n            <td>9</td>\r\n            <td>4</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-private-fields/issues/92\">can we just use private keyword?</a></td>\r\n            <td>2</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/142\">Do we still have a chance to stop private fields (with #)?</a></td>\r\n            <td>3</td>\r\n            <td>3</td>\r\n            <td>1</td>\r\n            <td>1</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/149\">[Private] yet another alternative to `#`-based syntax</a></td>\r\n            <td>3</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/153\">and yet another suggestion for \"private but not closure\"</a></td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/138\">Why don't use `private` instead of `#`?</a></td>\r\n            <td>0</td>\r\n            <td>3</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n        <tr>\r\n            <td><a href=\"https://github.com/tc39/proposal-class-fields/issues/116\">Why \"private\" and \"protected\" future reserved keywords are not used?</a></td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n            <td>0</td>\r\n        </tr>\r\n    </tbody>\r\n</table>\r\n\r\nOther feedback:\r\n\r\n* http://2ality.com/2017/07/class-fields.html\r\n    * From the comments: \"I'd rather shoot myself in the face than use hashtags for private fields.\"\r\n        * 33 upvotes (comments closed)\r\n* [ES Next Features That'll Make You Dance](https://www.youtube.com/watch?v=9yK4t2CuIHQ)\r\n    * [\"And beware, you may have an adverse reaction ...\"](https://youtu.be/9yK4t2CuIHQ?t=1148)\r\n    * [\"Oh, I heard somebody groan!\"](https://youtu.be/9yK4t2CuIHQ?t=1160)\r\n    * Some comments:\r\n        * > #method() is gross, at least I use typescript and don't have to look at it. 👍30\r\n        * > So ES is becoming the new PHP \"ugly-wise\"? So glad i use typescript. They should have delayed that private method feature some more and thought some more to really avoid having that absolutely terrible, horrible looking # syntax. Ew.. In code everything is possible. EVERYTHING (if your not into computer science). If they have to break backward compat then so be it. So very bad.\r\n        * > I am excited about getting new features and I like to see things continuing to grow, I am not liking that private property syntax in the function, it looks like a comment and makes me shudder... everyone should be aware of this \"fact\" - every time someone gets confused and thinks the # symbol is actually a comment when JavaScript should have used the word private to declare a private entity, a bag of kittens gets thrown into a wood chipper, very sad.﻿\r\n        * > Fix the private keyword issue please! The proposed syntax is not only inconsistent with the static declaration but also looks like a comment!\r\n\r\nThe TypeScript team are [not fond of](https://github.com/Microsoft/TypeScript/issues/16415) the syntax either.\r\n\r\nMy suggestion to rename the proposal: https://github.com/tc39/proposal-private-fields/issues/72\r\n(the idea is mainly about making it a lower-level feature, and making room for a cleaner syntax at a later date)\r\n\r\n@littledan @bakkot @ljharb – I apologize in advance, as I know that you must be thinking \"Oh g*d, not again!\", but I just wanted to put this all in one place, and allow the community to share their opinion in the form of reactions. It would be great if you could keep this open for a while (30 days?), or perhaps even indefinitely to prevent other users from submitting even more issues on the same topic.\r\n\r\nTo the non-committee members reading this: These proposals are now at stage 3, so it's unlikely that a syntax change will occur, but please feel free to up-vote this issue if you feel that the sigil (`#`) prefix is not a good fit for the language, or down-vote the issue if you believe that it's perfectly acceptable."},"comment":{"url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/comments/439873155","html_url":"https://github.com/tc39/proposal-class-fields/issues/100#issuecomment-439873155","issue_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/100","id":439873155,"node_id":"MDEyOklzc3VlQ29tbWVudDQzOTg3MzE1NQ==","user":{"login":"hax","id":159840,"node_id":"MDQ6VXNlcjE1OTg0MA==","avatar_url":"https://avatars0.githubusercontent.com/u/159840?v=4","gravatar_id":"","url":"https://api.github.com/users/hax","html_url":"https://github.com/hax","followers_url":"https://api.github.com/users/hax/followers","following_url":"https://api.github.com/users/hax/following{/other_user}","gists_url":"https://api.github.com/users/hax/gists{/gist_id}","starred_url":"https://api.github.com/users/hax/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hax/subscriptions","organizations_url":"https://api.github.com/users/hax/orgs","repos_url":"https://api.github.com/users/hax/repos","events_url":"https://api.github.com/users/hax/events{/privacy}","received_events_url":"https://api.github.com/users/hax/received_events","type":"User","site_admin":false},"created_at":"2018-11-19T12:13:22Z","updated_at":"2018-11-19T12:13:22Z","author_association":"NONE","body":"@mbrown \r\n\r\n> But I agree with @ljharb; this is not about React, but the issue in general.\r\n\r\nHow general? \r\n\r\nIf we agree React class-based component use case is not valid, we first need to present other use cases. And I will glad to analyze them one by one. I can do it all day. 😜\r\n\r\n> I haven't seen many objections to public fields but rather a lot of support for them, and people already using them and liking them\r\n\r\nBecause it's very hard to see the full consequences of the a proposal for average programmers. This is why we need TC39, isn't it? \r\n\r\nIt's ok to use and like any language feature if it just solve your \"problems\". Most programmers never care about where such \"problems\" come from. Actually many teams in my company also use React and class field! And they all like it! So what? They don't notice the dark side just because they only use it in React and no one tell them the bad part. (I decided not bother them uptonow. But someone in the team already notice the discussions here and ask me to give a presentation this Thursday. It will be a bad day for them. 😢)\r\n\r\nActually I never discuss the controversial issues of tc39 proposals in public even I attend 20+ conferences every year. (Not only this proposal, but also other controversial issues.) I gave a speech about private field syntax in a large conference last year, just because I used to believe this is the only solution, and I hope the community could accept it. But I found I was wrong. \r\n\r\nI never want to tell the community TC39 is doing something which may be wrong. This is harmful to the relationship between the community and the committee. \r\n\r\nAnd It's very tough and annoying for average programmers to understand the issue of the spec/proposals. In fact, if it was easy to handle, TC39 should already solved them! If TC39 can not solve them, how could you expect programmers to behave? So why bother programmers? They already have many real life issues! \r\n\r\nSo it's nothing wrong for programmers to using/liking a feature if it make their life easier.\r\n\r\nBut it's wrong for TC39 only see the programmers using/liking it in a special case (i.e. in React or similar component framework usage, and such cases may be not a valid use case to support the proposal) and ignore the complex consequences for the whole ecosystem.\r\n\r\n\r\n> at least as implemented by TypeScript and Babel 6 (and yes, that's an important caveat which is one of the reasons why I've been advocating for [[Set]] semantics). There are lots of other frameworks and libraries that rely on external access to public instance properties and would break without it, including some with very similar patterns to React, e.g. [Aurelia](https://aurelia.io/docs/fundamentals/components#creating-a-component) and [lit-element](https://github.com/Polymer/lit-element). \r\n\r\nThey will never break because they rely on TypeScript/Babel. Saying \"you will break the frameworks/libraries if you don't land such feature\" is just hijacking, with such logic, we have to land JSX first. 🤪\r\n\r\nLooking inside Lit-element, `@property()  foo = 'foo'` could be easily transform to `@property()  <keyword> foo = 'foo'` as classes 1.1 proposal. The `property` decorator need to rewrite to generator getter/setter pair to wrap `foo` instance variable, but client codes have no other difference. Aurelia is similar. You may need to change some code (add keyword, add decorator), but it could be automated by codemod in most cases.\r\n\r\n\r\n\r\n\r\n> And more importantly, public field declarations just make sense for the language, considering that:\r\n> \r\n> * We've always had them and just want a more declarative syntax for them; public properties are not going away\r\n\r\nPrivate with syntax sugar or decorators for getter/setter pairs could also provide the declarative syntax, without footguns of public field.\r\n\r\n> but no such alternative exists and it's too late to change the fundamental semantics of getters/setters to provide some sort of shortcut.\r\n\r\nDon't understand why we need change anything. Actually if the private field is based on private symbol (which means they are just normal property that current decorator spec already can handle) we just could write such decorators now!\r\n\r\n> * There are perfectly legitimate use cases for public fields (however rare they may be), and refactoring to use getters/setters instead if needed for encapsulation purposes in the future is always an option\r\n\r\nNo, refactor will be footgun ([[Set]] vs [[Define]]) if there is inheritance. Only [[Set]] is safe, and if [[Set]], this is not public field proposal, but initializer syntax sugar proposal.\r\n\r\n> * Some developers are fine with enforcing encapsulation on their own (rather than the language enforcing it), via conventions like underscore-prefixed properties and will want to continue doing that. This is the Python philosophy of \"we're all adults here\"...I don't really agree with it but to each his/her own. Basically the point here is not to impose the same philosophy on everyone especially when it's contrary to the already-established conventions of the language.\r\n\r\nI don't think getter/setter wrapper enforcing anything. Basically it's just a better public property, you will never know whether it's public property or getter/setter without reflection.\r\n\r\n\r\nPS. Some words about python philosophy... Such philosophy really should apply to the key factor leading to `#` --- there is no much programmers want hard private. Only some framework want it, and note: other framework may hate it, for example, hard private will break Vue, because Vue need to collect dependencies by getter/setter or proxy on runtime, and hard private can't be tracked at all. So why not add `Symbol.private` and let them encapsulation by themself? And it also allow the author expose the private symbols to the frameworks (such as Vue, or test framework) which need them to work correctly.\r\n\r\n"}}
{"actor":{"display_login":"hax"}}