{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-private-fields/issues/47","repository_url":"https://api.github.com/repos/tc39/proposal-private-fields","labels_url":"https://api.github.com/repos/tc39/proposal-private-fields/issues/47/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-private-fields/issues/47/comments","events_url":"https://api.github.com/repos/tc39/proposal-private-fields/issues/47/events","html_url":"https://github.com/tc39/proposal-private-fields/issues/47","id":173012998,"number":47,"title":"Accessing fields from within 'eval'","user":{"login":"bakkot","id":1653598,"avatar_url":"https://avatars.githubusercontent.com/u/1653598?v=3","gravatar_id":"","url":"https://api.github.com/users/bakkot","html_url":"https://github.com/bakkot","followers_url":"https://api.github.com/users/bakkot/followers","following_url":"https://api.github.com/users/bakkot/following{/other_user}","gists_url":"https://api.github.com/users/bakkot/gists{/gist_id}","starred_url":"https://api.github.com/users/bakkot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bakkot/subscriptions","organizations_url":"https://api.github.com/users/bakkot/orgs","repos_url":"https://api.github.com/users/bakkot/repos","events_url":"https://api.github.com/users/bakkot/events{/privacy}","received_events_url":"https://api.github.com/users/bakkot/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":15,"created_at":"2016-08-24T17:33:30Z","updated_at":"2016-11-17T16:35:29Z","closed_at":null,"body":" I think it would make sense to ban access to private fields through `eval`, on the basis that dynamic access to private fields is contrary to \"private\".\n\nFor example, I would be happier if this pattern were illegal:\n\n``` js\nclass C {\n  getPrivate(s) { return eval(s); }\n  #prop = 0;\n}\n\n(new C).getPrivate('#prop'); // 0\n```\n## \n\nNote that this does not mean banning the use of private state within a call to `eval` as long as the field is itself declared as a part of the call. I think this is fine (insofar as `eval` is ever fine):\n\n``` js\neval(`\nclass C {\n  getProp(){ return #prop; }\n  #prop = 0;\n}\n(new C).getProp();\n`); // 0\n```\n"},"comment":{"url":"https://api.github.com/repos/tc39/proposal-private-fields/issues/comments/261297100","html_url":"https://github.com/tc39/proposal-private-fields/issues/47#issuecomment-261297100","issue_url":"https://api.github.com/repos/tc39/proposal-private-fields/issues/47","id":261297100,"user":{"login":"littledan","id":189835,"avatar_url":"https://avatars.githubusercontent.com/u/189835?v=3","gravatar_id":"","url":"https://api.github.com/users/littledan","html_url":"https://github.com/littledan","followers_url":"https://api.github.com/users/littledan/followers","following_url":"https://api.github.com/users/littledan/following{/other_user}","gists_url":"https://api.github.com/users/littledan/gists{/gist_id}","starred_url":"https://api.github.com/users/littledan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/littledan/subscriptions","organizations_url":"https://api.github.com/users/littledan/orgs","repos_url":"https://api.github.com/users/littledan/repos","events_url":"https://api.github.com/users/littledan/events{/privacy}","received_events_url":"https://api.github.com/users/littledan/received_events","type":"User","site_admin":false},"created_at":"2016-11-17T16:35:29Z","updated_at":"2016-11-17T16:35:29Z","body":"I don't think this symmetry is particularly useful in this sort of context. `eval` is useful for loading code, e.g. in legacy \"module\" systems. Sometimes, you may be loading a bunch of pieces of code into a closure, where they should be able to see each other, so this justifies sharing local variables. However, I don't think we need to expose private state this way.\r\n\r\nI think it would be useful for developers' logic to have the invariant that private state is only accessed by code which is textually present; that's the invariant I'm trying to preserve. Do you think that invariant doesn't have its own value, despite the fact that it's not an SES-style security issue?"}}
{"actor":{"display_login":"littledan"}}