{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/193","repository_url":"https://api.github.com/repos/tc39/proposal-class-fields","labels_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/193/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/193/comments","events_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/193/events","html_url":"https://github.com/tc39/proposal-class-fields/issues/193","id":394211717,"node_id":"MDU6SXNzdWUzOTQyMTE3MTc=","number":193,"title":"Public class fields is problematic. Please hold.","user":{"login":"panlina","id":18240847,"node_id":"MDQ6VXNlcjE4MjQwODQ3","avatar_url":"https://avatars2.githubusercontent.com/u/18240847?v=4","gravatar_id":"","url":"https://api.github.com/users/panlina","html_url":"https://github.com/panlina","followers_url":"https://api.github.com/users/panlina/followers","following_url":"https://api.github.com/users/panlina/following{/other_user}","gists_url":"https://api.github.com/users/panlina/gists{/gist_id}","starred_url":"https://api.github.com/users/panlina/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/panlina/subscriptions","organizations_url":"https://api.github.com/users/panlina/orgs","repos_url":"https://api.github.com/users/panlina/repos","events_url":"https://api.github.com/users/panlina/events{/privacy}","received_events_url":"https://api.github.com/users/panlina/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":30,"created_at":"2018-12-26T17:43:22Z","updated_at":"2019-01-05T23:41:58Z","closed_at":"2019-01-04T11:59:59Z","author_association":"NONE","body":"I'm not so involved in this proposal as many others here before, but recently I've been studying this proposal, including the `[[Define]]` vs. `[[Set]]` debate. After that I find the idea of class fields is problematic in the current way of implementation.\r\n\r\nJavaScript is well known for its prototype based OO. It let every object have a prototype and property accesses goes up the prototype chain, and that makes it look like the object inherits properties from its prototype. This feature is natural to implement OO.\r\n\r\nHowever, JavaScript does not tell you how this mechanism is mapped to OO concepts.\r\n\r\n* Methods need to be shared between instances. This can be done by defining an object containing methods and set it as prototype of instances, as the `new` operator will do.\r\n* An object of the derived class needs to inherit (data) properties of an object of the base class. This can be done by defining the base instance directly as the prototype of the derived instance.\r\n\r\nEither is using the prototype to propagate property sets. Unfortunately, there's the restriction of prototypes in the language: **an object can only have one prototype.** We have only 1 channel but 2 threads.\r\n\r\nInevitably, we have to cut off one path. In es6, we choose to cut off the prototype chain of inheritance, and what actually happens is that we do not create instances for every base class, instead we let them be the most derived object itself.\r\n\r\nAs shown [here](http://2ality.com/2015/02/es6-classes-final.html#the-details-of-subclassing), prototypes of instances form decent chain, but there's no such for instances themselves.\r\n\r\nNow based on this selected model, we are introducing fields. We must not dismiss the fact that:\r\n\r\n**We do not have instance prototype chain anyway!**\r\n\r\nDue to the absence of the instance prototype chain, *field* becomes a false concept. Any operation performed by the language that `[[DefineOwnProperty]]` on the instance for fields makes no sense and/or introduce inconsistent behavior. Many examples are given in this repo.\r\n\r\nI'm not saying that fields are not possible in JavaScript. Conceptually, they are nearly trivial, and `[[Define]]` is the obvious choice to take--in class context, we are declaring it, so why `[[Set]]`(To clarify, `[[Define]]` is only for the declaration part, not the initialization part)? `[[Define]]`ing [data properties](https://tc39.github.io/ecma262/#sec-object-type) on each level on the instance inheritance chain should work consistently and intuitively.\r\n\r\nThe conclusion to say field is a false concept is based on the object model since es6. It is the essential cause that is making public fields proposal so controversial, but we can not abandon it.\r\n\r\nSo it is hardly possible to let JavaScript have fields resembling other OO languages in next version. Currently my opinion of the public fields proposal is:\r\n\r\n1. Hold back.\r\n2. If we must have public fields, use `[[Set]]` semantics, and would be better to reconsider it as `property initializer`.\r\n3. Please do not let `[[Define]]` be the standard. 😢 \r\n\r\nPS:\r\n\r\nTo expand a little if it's not clear, another model can be to cut off the other path. We let instances form prototype chain, and manually copy methods onto instances. But this gives up the benefits of built-in `new` operator and methods sharing.\r\n\r\nTo expand further, if we are not limited to only 1 prototype, for example, introducing `[[InstancePrototype]]`, this difficulty can be solved with less trade-off, but will bring complexity, though.\r\n"},"comment":{"url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/comments/451701923","html_url":"https://github.com/tc39/proposal-class-fields/issues/193#issuecomment-451701923","issue_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/193","id":451701923,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MTcwMTkyMw==","user":{"login":"rdking","id":2289634,"node_id":"MDQ6VXNlcjIyODk2MzQ=","avatar_url":"https://avatars0.githubusercontent.com/u/2289634?v=4","gravatar_id":"","url":"https://api.github.com/users/rdking","html_url":"https://github.com/rdking","followers_url":"https://api.github.com/users/rdking/followers","following_url":"https://api.github.com/users/rdking/following{/other_user}","gists_url":"https://api.github.com/users/rdking/gists{/gist_id}","starred_url":"https://api.github.com/users/rdking/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rdking/subscriptions","organizations_url":"https://api.github.com/users/rdking/orgs","repos_url":"https://api.github.com/users/rdking/repos","events_url":"https://api.github.com/users/rdking/events{/privacy}","received_events_url":"https://api.github.com/users/rdking/received_events","type":"User","site_admin":false},"created_at":"2019-01-05T23:41:58Z","updated_at":"2019-01-05T23:41:58Z","author_association":"NONE","body":"@littledan \r\n> Honestly, at this point, it feels like arguments are being brought up not for the sake of trying to help improve the feature, but rather just to make the generic case that this proposal should not be shipped. I hope I am wrong about that; such a discussion style doesn't seem so productive.\r\n\r\nThat's backwards. The proposal shouldn't be shipped because so many issues like this remain unfixed. If these issues didn't exist, if decorators was guaranteed to ship together with class-fields, then I wouldn't be putting up nearly as much of a fuss as I have. The fundamental truth is that given the paradigm chosen, TC39 has done the best they can. We want TC39 to recognize that the problem is the paradigm itself!!!! It is the very approach taken that has lead so many of us to keep boring you with the repeated re-raising of issues.\r\n\r\n@littledan @bakkot \r\nStop telling us \"what\" you've chosen and start telling us \"why\" so we can see for ourselves and/or point out to you (TC39) why the choice you've made is not the best. Remember that the priority of value on arguments is in order, \"logical/technical\", \"rational/use case\", \"emotional/user reaction\". An argument based on how you feel about something is not as strong as an argument that affects how things will be used, which itself is not as strong as an argument about what is and is not possible.\r\n\r\n@ljharb \r\nThank you for being one to spend time trying to explain some of the \"why\". We've all needed that. And speaking for myself, despite being such an ardent protestor against this proposal, I hope I've managed to show you that with an adequate argument, even my opinion can be swayed. If you can, help the other proponents do the same as you have. At the same time, don't be so quick to \"die on a hill\" over something you don't like. 😜 "}}
{"actor":{"display_login":"rdking"}}