{"action":"created","issue":{"url":"https://api.github.com/repos/jeffmo/es-class-fields-and-static-properties/issues/33","repository_url":"https://api.github.com/repos/jeffmo/es-class-fields-and-static-properties","labels_url":"https://api.github.com/repos/jeffmo/es-class-fields-and-static-properties/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/jeffmo/es-class-fields-and-static-properties/issues/33/comments","events_url":"https://api.github.com/repos/jeffmo/es-class-fields-and-static-properties/issues/33/events","html_url":"https://github.com/jeffmo/es-class-fields-and-static-properties/issues/33","id":145021724,"number":33,"title":"Syntactic ideas to try to clarify the different execution time and scoping","user":{"login":"domenic","id":617481,"avatar_url":"https://avatars.githubusercontent.com/u/617481?v=3","gravatar_id":"","url":"https://api.github.com/users/domenic","html_url":"https://github.com/domenic","followers_url":"https://api.github.com/users/domenic/followers","following_url":"https://api.github.com/users/domenic/following{/other_user}","gists_url":"https://api.github.com/users/domenic/gists{/gist_id}","starred_url":"https://api.github.com/users/domenic/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/domenic/subscriptions","organizations_url":"https://api.github.com/users/domenic/orgs","repos_url":"https://api.github.com/users/domenic/repos","events_url":"https://api.github.com/users/domenic/events{/privacy}","received_events_url":"https://api.github.com/users/domenic/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":39,"created_at":"2016-03-31T21:19:57Z","updated_at":"2016-04-04T19:58:02Z","closed_at":null,"body":"At the March TC39 meeting, I and others were able to articulate our misgivings about the current proposal. The obviously troublesome cases are things like:\r\n\r\n```js\r\nclass C {\r\n  [this.bar] = this.bar;\r\n  [baz] = baz;\r\n}\r\n```\r\n\r\nwhere the left-hand side executes at a completely different time, and in a completely different scope, than the right-hand side. Myself in particular find the idea of two sides of an `=` sign having different bindings to be just too strange.\r\n\r\nI think this could be helped with syntactic work to make it clear that the right-hand side is a \"thunk\" executing later and in a different scope. Here are some strawmen ideas:\r\n\r\n```js\r\n  [baz] := baz // at least makes it clear this is not straightforward =\r\n  [baz] := { return baz; } // very clear this is a thunk\r\n  // or allow both, i.e. use arrow function body-esque rules?\r\n\r\n  [baz] := do { baz; } // use do expressions as the thunk (allows omitting return)\r\n  [baz] do= { baz; } // !?!?\r\n\r\n  // or any of the above using different sigils, e.g.:\r\n  [baz] <- { return baz; }\r\n  [baz] <- { baz; }\r\n```\r\n\r\nI think this is particularly important in some of the common use cases, e.g. \"method binding\":\r\n\r\n```js\r\nclass C {\r\n  method = (foo) => bar;\r\n}\r\n```\r\n\r\nI have seen people do this just because they like arrow functions and want the concise body, not realizing that this is a significant semantic shift: removing the prototype property, and creating a new function instance every time a `C` is constructed. People's mental model, in other words, is that this is only evaluated once.\r\n\r\nContrast:\r\n\r\n```js\r\nclass C {\r\n  method := { return (foo) => bar; }\r\n}\r\n```\r\n\r\nHere it should be intuitively clear from looking at the code that there's a bit of code that will run, creating and returning a new arrow function every time. That's hugely beneficial."},"comment":{"url":"https://api.github.com/repos/jeffmo/es-class-fields-and-static-properties/issues/comments/205469555","html_url":"https://github.com/jeffmo/es-class-fields-and-static-properties/issues/33#issuecomment-205469555","issue_url":"https://api.github.com/repos/jeffmo/es-class-fields-and-static-properties/issues/33","id":205469555,"user":{"login":"jeffmo","id":498293,"avatar_url":"https://avatars.githubusercontent.com/u/498293?v=3","gravatar_id":"","url":"https://api.github.com/users/jeffmo","html_url":"https://github.com/jeffmo","followers_url":"https://api.github.com/users/jeffmo/followers","following_url":"https://api.github.com/users/jeffmo/following{/other_user}","gists_url":"https://api.github.com/users/jeffmo/gists{/gist_id}","starred_url":"https://api.github.com/users/jeffmo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jeffmo/subscriptions","organizations_url":"https://api.github.com/users/jeffmo/orgs","repos_url":"https://api.github.com/users/jeffmo/repos","events_url":"https://api.github.com/users/jeffmo/events{/privacy}","received_events_url":"https://api.github.com/users/jeffmo/received_events","type":"User","site_admin":false},"created_at":"2016-04-04T19:58:02Z","updated_at":"2016-04-04T19:58:02Z","body":"Good point. To be clear, though: I wasn't necessarily suggesting omitting computed field-names -- only making sure @wycats could represent any upsides/downsides to evaluating LHS at instantiation time.\r\n\r\nI personally would find this odd, but I'd probably want to think about it more. I'm not sure I could do a great job of representing the position of someone who plans on using computed field names at the moment :)"}}