{"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":9,"created_at":"2016-01-08T15:47:08Z","updated_at":"2016-01-11T17:50:08Z","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/170632456","html_url":"https://github.com/zenparsing/es-private-fields/issues/17#issuecomment-170632456","issue_url":"https://api.github.com/repos/zenparsing/es-private-fields/issues/17","id":170632456,"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-11T17:50:08Z","updated_at":"2016-01-11T17:50:08Z","body":"@littledan Yeah, there are some nice properties here.  Also, the super constructor can do \"return overriding\" and everything works like the user would expect.\r\n\r\nExploring this idea further: one of the primary motivations for a static [[InstanceSlots]] was to provide engines with an \"early\" way to determine the \"shape\" of an object based on the constructor, thereby allowing performance optimizations.  What might be the performance impact of dynamic private slots, from a V8 perspective?"}}