{"action":"closed","issue":{"url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/123","repository_url":"https://api.github.com/repos/tc39/proposal-class-fields","labels_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/123/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/123/comments","events_url":"https://api.github.com/repos/tc39/proposal-class-fields/issues/123/events","html_url":"https://github.com/tc39/proposal-class-fields/issues/123","id":351269225,"node_id":"MDU6SXNzdWUzNTEyNjkyMjU=","number":123,"title":"Fields not applied to prototype","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},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":49,"created_at":"2018-08-16T16:01:14Z","updated_at":"2018-08-20T12:38:51Z","closed_at":"2018-08-20T12:38:51Z","author_association":"NONE","body":"I just finished looking over proposal-decorators. It reminds me of Java Annotations, which I have mixed feelings about, but I can see it as a very useful way of solving the _mixin_ issue. What I noticed, however, was that in the example for @prototypeProp, by default, fields will be applied directly to instances. This makes no sense. Not only does this immediately conflict with the point of having a constructor function, it also conflicts with the fact that `class` is meant to build a prototype out of the description it is given. There is very literally nothing to gain by sidestepping the prototype inheritance mechanism to inject values directly on an instance without the assistance of the constructor. \r\n\r\nThe `class` keyword is meant to produce a prototype and, if the prototype doesn't contain a `constructor` function, a default constructor. I would assume this is being done this way because the current design directly places private fields in slots of an instance just before calling the constructor. This too is not a good idea. The design and management of private fields should be congruent with the design and management of public fields. This will reduce the risk of developers encountering an unexpected outcome."}}
{"actor":{"display_login":"rdking"}}