{"action":"created","issue":{"url":"https://api.github.com/repos/claudepache/es-regexp-legacy-static-properties/issues/6","repository_url":"https://api.github.com/repos/claudepache/es-regexp-legacy-static-properties","labels_url":"https://api.github.com/repos/claudepache/es-regexp-legacy-static-properties/issues/6/labels{/name}","comments_url":"https://api.github.com/repos/claudepache/es-regexp-legacy-static-properties/issues/6/comments","events_url":"https://api.github.com/repos/claudepache/es-regexp-legacy-static-properties/issues/6/events","html_url":"https://github.com/claudepache/es-regexp-legacy-static-properties/issues/6","id":151100087,"number":6,"title":"How to disable RegExp.$1, etc. for proper subclasses of RegExp","user":{"login":"claudepache","id":3309637,"avatar_url":"https://avatars.githubusercontent.com/u/3309637?v=3","gravatar_id":"","url":"https://api.github.com/users/claudepache","html_url":"https://github.com/claudepache","followers_url":"https://api.github.com/users/claudepache/followers","following_url":"https://api.github.com/users/claudepache/following{/other_user}","gists_url":"https://api.github.com/users/claudepache/gists{/gist_id}","starred_url":"https://api.github.com/users/claudepache/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/claudepache/subscriptions","organizations_url":"https://api.github.com/users/claudepache/orgs","repos_url":"https://api.github.com/users/claudepache/repos","events_url":"https://api.github.com/users/claudepache/events{/privacy}","received_events_url":"https://api.github.com/users/claudepache/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2016-04-26T10:40:06Z","updated_at":"2016-04-27T17:59:36Z","closed_at":null,"body":"For concreteness, consider:\r\n\r\n```js\r\nclass MyRegExp extends RegExp {  }\r\nlet rx = new MyRegExp('(foo)');\r\nrx.exec('foobar'); // <-- what action should be taken w.r.t. RegExp.$1, etc.\r\nRegExp.$1; // <-- what should evaluate this expression to?\r\n```\r\n\r\nIf we want to disable `RegExp.$1` here, there are three options:\r\n\r\n1. Do nothing. — `RegExp.$1` will evaluate to a value captured during the preceding successful match done with a plain regexp.\r\n2. Empty `RegExp.$1`, etc. — `RegExp.$1` will evaluate to the empty string.\r\n3. Invalidate `RegExp.$1`, etc. — Evaluating `RegExp.$1` will throw a TypeError.\r\n\r\nComments:\r\n* Option 1 is the simplest, but the worst for the programmer, as RegExp.$1 will lead to some randomly false result.\r\n* Option 3 is better for debugging purposes, but might be dangerous for backward-compatibility, as buggy errant references to RegExp.$1 may start to randomly throw.\r\n* Option 2 is a trade-off: it avoids the hazard of Option 3, and it provides false but consistent results for use with proper subclasses of RegExp.\r\n\r\nAlthough Option 3 may be idealistically better, it is probably more prudent to use Option 2.\r\n"},"comment":{"url":"https://api.github.com/repos/claudepache/es-regexp-legacy-static-properties/issues/comments/215172134","html_url":"https://github.com/claudepache/es-regexp-legacy-static-properties/issues/6#issuecomment-215172134","issue_url":"https://api.github.com/repos/claudepache/es-regexp-legacy-static-properties/issues/6","id":215172134,"user":{"login":"erights","id":273868,"avatar_url":"https://avatars.githubusercontent.com/u/273868?v=3","gravatar_id":"","url":"https://api.github.com/users/erights","html_url":"https://github.com/erights","followers_url":"https://api.github.com/users/erights/followers","following_url":"https://api.github.com/users/erights/following{/other_user}","gists_url":"https://api.github.com/users/erights/gists{/gist_id}","starred_url":"https://api.github.com/users/erights/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/erights/subscriptions","organizations_url":"https://api.github.com/users/erights/orgs","repos_url":"https://api.github.com/users/erights/repos","events_url":"https://api.github.com/users/erights/events{/privacy}","received_events_url":"https://api.github.com/users/erights/received_events","type":"User","site_admin":false},"created_at":"2016-04-27T17:59:36Z","updated_at":"2016-04-27T17:59:36Z","body":"I don't understand. The two parts of your comment seem to contradict each other:\r\n\r\n> Currently, dumb Option 1 is specced\r\n\r\nvs\r\n\r\n> However, MyRegExp.$1 will now invariably return undefined.\r\n\r\nBut this does suggest an option 4:\r\n\r\nHave MyRegExp.$1 always return undefined, in order to be as compatible as possible with the absence of these static properties. The most common feature testing pattern would then perceive these features as being absent. Unfortunately, less common but more correct feature testing patterns, i.e., `\"$1\" in MyRegExp` would falsely perceive the feature as present. An even less common but still correct own check would again perceive the feature as absent.\r\n\r\nThis suggests an option 5: To make feature testing reliably indicate absence, we could make RegExp subclasses be exotic objects that report an absence of these properties even though they would non-exotically be inherited from their `[[Prototype]]`. Before considering this, we'd need to be sure that this illusion does not violate the object invariants, and that it could be emulated by a proxy.\r\n\r\nOption 5 seems much too complex given the minor benefit. Altogether, I favor option 3. There are two levels of legacy compatibility concerns we must always keep in mind:\r\n\r\n  * **don't break the web** only involves whole pages/frames/realms. None of these have RegExp subclasses, and so are compat with all of these options\r\n  * **invariants assumed by maintained code that is linked with other code**. For these, any invariants promised in one version of the spec should generally be upheld by later versions of the spec. Since RegExp statics have never been in the spec, this is a non-issue. On the other hand, this does argue against option 5."}}