{"action":"created","issue":{"url":"https://api.github.com/repos/zenparsing/es-private-fields/issues/17","labels_url":"https://api.github.com/repos/zenparsing/es-private-fields/issues/17/labels{/name}","comments_url":"https://api.github.com/repos/zenparsing/es-private-fields/issues/17/comments","events_url":"https://api.github.com/repos/zenparsing/es-private-fields/issues/17/events","html_url":"https://github.com/zenparsing/es-private-fields/issues/17","id":125635577,"number":17,"title":"Generalize spec internal slots as private fields?","user":{"login":"zenparsing","id":5995084,"avatar_url":"https://avatars.githubusercontent.com/u/5995084?v=3","gravatar_id":"","url":"https://api.github.com/users/zenparsing","html_url":"https://github.com/zenparsing","followers_url":"https://api.github.com/users/zenparsing/followers","following_url":"https://api.github.com/users/zenparsing/following{/other_user}","gists_url":"https://api.github.com/users/zenparsing/gists{/gist_id}","starred_url":"https://api.github.com/users/zenparsing/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zenparsing/subscriptions","organizations_url":"https://api.github.com/users/zenparsing/orgs","repos_url":"https://api.github.com/users/zenparsing/repos","events_url":"https://api.github.com/users/zenparsing/events{/privacy}","received_events_url":"https://api.github.com/users/zenparsing/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":20,"created_at":"2016-01-08T15:47:08Z","updated_at":"2016-01-25T16:27:59Z","closed_at":null,"body":"It would be ideal if private slots could be a strict generalization of the internal slots used by the ES spec for the private state of built-in objects.  Unfortunately, making this happen would require a breaking change to ES6.\r\n\r\nTo see why, consider this example:\r\n\r\n```js\r\nclass B extends A {\r\n    constructor() {\r\n        super();\r\n    }\r\n}\r\n\r\n// OK, now let's change the prototype chain to make it a Map subclass!\r\nObject.setPrototypeOf(B, Map);\r\nObject.setPrototypeOf(B.prototype, Map.prototype);\r\n\r\n// Now let's create an instance!\r\nlet b = new B();\r\n// Everything works OK\r\nb.set(\"a\", 1);\r\n```\r\n\r\nThat example works in ES6 because the Map constructor creates an object with a `[[MapData]]` internal slot.  The internal slot list of the allocated object is not affected by *NewTarget*.\r\n\r\nFor this proposal, the user-defined private slot list is determined by *NewTarget*, so you cannot swap constructor prototypes and expect things to work.\r\n\r\n```js\r\nclass B extends A {\r\n    constructor() {\r\n        super();\r\n    }\r\n}\r\n\r\nclass C {\r\n    #foo;\r\n    constructor() {\r\n        this.#foo = 1;\r\n    }\r\n}\r\n\r\n// OK, now let's change the prototype chain to make it a C subclass!\r\nObject.setPrototypeOf(B, C);\r\n\r\n// Now let's create an instance!\r\nlet b = new B();\r\n// Nope, that that fails because the object isn't allocated with a #foo slot...\r\n```\r\n\r\nI would prefer to remove this incongruence and re-spec all built-in internal slots using the same semantics as user-defined private slots, but that would be a breaking change.\r\n\r\nThoughts?\r\n\r\n@wycats\r\n@littledan\r\n@allenwb\r\n"},"comment":{"url":"https://api.github.com/repos/zenparsing/es-private-fields/issues/comments/174566508","html_url":"https://github.com/zenparsing/es-private-fields/issues/17#issuecomment-174566508","issue_url":"https://api.github.com/repos/zenparsing/es-private-fields/issues/17","id":174566508,"user":{"login":"zenparsing","id":5995084,"avatar_url":"https://avatars.githubusercontent.com/u/5995084?v=3","gravatar_id":"","url":"https://api.github.com/users/zenparsing","html_url":"https://github.com/zenparsing","followers_url":"https://api.github.com/users/zenparsing/followers","following_url":"https://api.github.com/users/zenparsing/following{/other_user}","gists_url":"https://api.github.com/users/zenparsing/gists{/gist_id}","starred_url":"https://api.github.com/users/zenparsing/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zenparsing/subscriptions","organizations_url":"https://api.github.com/users/zenparsing/orgs","repos_url":"https://api.github.com/users/zenparsing/repos","events_url":"https://api.github.com/users/zenparsing/events{/privacy}","received_events_url":"https://api.github.com/users/zenparsing/received_events","type":"User","site_admin":false},"created_at":"2016-01-25T16:27:59Z","updated_at":"2016-01-25T16:27:59Z","body":"@littledan Currently I have it doing option 2 (https://zenparsing.github.io/es-private-fields/#sec-addinternalslots).\r\n\r\nI was thinking that someone might want to have a pool where the super constructor returns a reclaimed  object from the pool, and then the subclass would want the fields \"zero'd\" out to undefined.  It's a stretch, admittedly.\r\n\r\nWhat are your reasons for preferring option 1?"}}