{"action":"opened","issue":{"url":"https://api.github.com/repos/wycats/javascript-decorators/issues/71","repository_url":"https://api.github.com/repos/wycats/javascript-decorators","labels_url":"https://api.github.com/repos/wycats/javascript-decorators/issues/71/labels{/name}","comments_url":"https://api.github.com/repos/wycats/javascript-decorators/issues/71/comments","events_url":"https://api.github.com/repos/wycats/javascript-decorators/issues/71/events","html_url":"https://github.com/wycats/javascript-decorators/issues/71","id":149309010,"number":71,"title":"Property initializers","user":{"login":"fatfisz","id":6004414,"avatar_url":"https://avatars.githubusercontent.com/u/6004414?v=3","gravatar_id":"","url":"https://api.github.com/users/fatfisz","html_url":"https://github.com/fatfisz","followers_url":"https://api.github.com/users/fatfisz/followers","following_url":"https://api.github.com/users/fatfisz/following{/other_user}","gists_url":"https://api.github.com/users/fatfisz/gists{/gist_id}","starred_url":"https://api.github.com/users/fatfisz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fatfisz/subscriptions","organizations_url":"https://api.github.com/users/fatfisz/orgs","repos_url":"https://api.github.com/users/fatfisz/repos","events_url":"https://api.github.com/users/fatfisz/events{/privacy}","received_events_url":"https://api.github.com/users/fatfisz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-04-19T00:21:55Z","updated_at":"2016-04-19T00:21:55Z","closed_at":null,"body":"Continuing from https://phabricator.babeljs.io/T2005 and #41 (I don't recommend reading the latter issue though).\r\n\r\nCurrently property decorators for both classes and objects operate on a descriptor pseudo-property \"initializer\", based on [this document](https://github.com/wycats/javascript-decorators/blob/master/interop/initializer.md). In my opinion this is over-complicating and also misleading in the case of class properties, because:\r\n* This descriptor property is not used anywhere else; it won't even be found in the [class fields and static properties spec](https://github.com/jeffmo/es-class-fields-and-static-properties) - initializers for the class fields are kept as simple functions (not descriptors).\r\n* It differentiates between the properties and the methods, e.g.:\r\n\r\n  ```js\r\n  {\r\n    @foo\r\n    bar() {}\r\n  }\r\n  ```\r\nand\r\n\r\n  ```js\r\n  {\r\n    @foo\r\n    bar: function() {}\r\n  }\r\n  ```\r\n`foo` has to handle two different versions of decorators for these cases.\r\n* The \"initializer\" property exists because of class properties, which are sugar for initializing instance properties in the constructor. I think it is misleading that the decorators are applied only once, whereas the initializers are called each time the class is instantiated.\r\n\r\n---\r\nIn the first referred issue @wycats says:\r\n> It's a critical constraint that decorators can run only once when the class is built and not add additional runtime cost unless the decorator chooses to add cost (by wrapping, for example). You can achieve both goals via initializer functions, but deferring the decorator until instantiation adds unavoidable cost.\r\n\r\nSo there is a performance concern. But still, for me the least surprise is more important. If I wanted to write really performant code, I wouldn't use decorators at all - they make life easier only for the programmer and not for the machine that will be executing the code.\r\n\r\n@isiahmeadows @jayphelps @jeffmo @loganfsmyth @lukescott Could you please weigh in on this?"}}