Changing [[Prototype]]
Le 24/12/2012 10:48, Anne van Kesteren a écrit :
I thought I'd give a heads up as over on www-dom at w3.org we're discussing two cases where we likely need to change the prototype chain of objects: document.open() and methods that do the equivalent of document.adoptNode() (including that method itself):
lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg143
Thanks for the heads up!
It seems ES6 has proto which also allows modifying [[Prototype]] so presumably this is nothing particularly bad, although it is very ugly :-(
The ability to change the [[Prototype]] of an object is orthogonal to the proto problem. If it's necessary for DOM objects to change the [[Prototype]] for backward-compat or security reasons, it can do so, I guess. proto is about author being allowed to change the [[Prototype]].
One thing to keep in mind, under no circomstances an object with [[Extensible]]:false can have its [[Prototype]] changed. The solution is either to forbid the change to [[Extensible]]:false (by throwing when about to) or forbid changing the [[Prototype]].
With the problem at hand and the solution currently being proposed (nodes changing of [[Prototype]] on adoptNode), it will remain possible to observe objects changing of [[Prototype]] after a "delete Object.prototype.proto". I don't know to what extends it's a good or a bad thing, but I thought it's worth mentionning.
David
Le 24/12/2012 10:48, Anne van Kesteren a écrit :
That doesn't seem to be a problem. Host objects may be losing most/all of their magic but it's certainly reasonable that they have privileged access to capabilities. I think it makes sense to frame deleting proto as simply removing access to a capability from the user, but the capability still theoretically existing if you somehow have privileged access to use it.
I think a bigger question is how DOM nodes will handle non-extensibility. If I Object.preventExtensions a node and then this scenario happens, which happens to that node? Or do nodes just start throwing whenever you try to make them non-extensible? I don't even know what happens currently, come to think of it. It's certainly not a common or useful thing to do.
Le 24/12/2012 15:50, Brandon Benvie a écrit :
That doesn't seem to be a problem. Host objects may be losing most/all of their magic but it's certainly reasonable that they have privileged access to capabilities. I think it makes sense to frame deleting proto as simply removing access to a capability from the user, but the capability still theoretically existing if you somehow have privileged access to use it.
Some may rely on [[Prototype]] not changing to prove JS programs. If you delete proto and use this knowledge to assume [[Prototype]] while it changes behind your back, it's not really helpful. While I'm saying this, I realize that the set of operations which will change [[Prototype]] is (will be) well-defined and the exact [[Prototype]] it changes to is not arbitrary. So maybe things are fine.
I think a bigger question is how DOM nodes will handle non-extensibility. If I Object.preventExtensions a node and then this scenario happens, which happens to that node? Or do nodes just start throwing whenever you try to make them non-extensible?
The throwing is what I suggested at www-dom.
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
I thought I'd give a heads up as over on www-dom at w3.org we're discussing two cases where we likely need to change the prototype chain of objects: document.open() and methods that do the equivalent of document.adoptNode() (including that method itself):
Thank for the heads up. I'll chat with bz to get more of the back story. This is pretty effing awful. It may in fact be unavoidable but I'd like to make sure I understand why people feel there's no alternative; otherwise I may have to consider throwing my already mangled body in front of yet another train... ;-)
It seems ES6 has proto which also allows modifying [[Prototype]] so presumably this is nothing particularly bad, although it is very ugly :-(
It is never safe to assume that just because something is out there on the web that it is "nothing particularly bad"... (FML)
On Dec 24, 2012, at 2:17 AM, David Bruant <bruant.d at gmail.com> wrote:
The ability to change the [[Prototype]] of an object is orthogonal to the proto problem. If it's necessary for DOM objects to change the [[Prototype]] for backward-compat or security reasons, it can do so, I guess. proto is about author being allowed to change the [[Prototype]].
Somewhat orthogonal. But if there's an API that can mutate prototypes, then authors can still do so at least indirectly on at least some kinds of objects.
We've given up on the (non-existent) invariant that [[Prototype]] is immutable. That doesn't mean we should set caution to the wind and specify standard libraries that mutate [[Prototype]] links whenever it happens to solve some problem.
Dave, caremad
Le 27/12/2012 06:40, David Herman a écrit :
We've given up on the (non-existent) invariant that [[Prototype]] is immutable. That doesn't mean we should set caution to the wind and specify standard libraries that mutate [[Prototype]] links whenever it happens to solve some problem.
As you'll see in the www-dom thread, I've tried really hard to find better ideas (or I guess rather understanding the problem better). The window (no pun) of opportunity is really small because "it'd be web-breaking" comes back often.
I'm in hope but doubtful a better solution can be found.
On 27 December 2012 06:38, David Herman <dherman at mozilla.com> wrote:
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
It seems ES6 has proto which also allows modifying [[Prototype]] so presumably this is nothing particularly bad, although it is very ugly :-(
It is never safe to assume that just because something is out there on the web that it is "nothing particularly bad"... (FML)
I'm not surprised to read this, though. Putting mutable proto into the language is far more than just regulating existing practice. It is blessing it. That is a psychological factor that should not be underestimated. I fully expect to see significantly more code in the future that considers it normal to use this feature, and that no amount of evangelization can counter the legislation precedent.
That is, if having it at all, I'd still think it much wiser to ban it to some Appendix.
On Thu, Dec 27, 2012 at 6:38 AM, David Herman <dherman at mozilla.com> wrote:
Thank for the heads up. I'll chat with bz to get more of the back story. This is pretty effing awful. It may in fact be unavoidable but I'd like to make sure I understand why people feel there's no alternative; otherwise I may have to consider throwing my already mangled body in front of yet another train... ;-)
For what it's worth, I'm good either way. I just want implementations to do the same thing. If we can avoid having to mutate [[Prototype]] in DOM and HTML I'd prefer that as it's less work for me. :-)
It seems ES6 has proto which also allows modifying [[Prototype]] so presumably this is nothing particularly bad, although it is very ugly :-(
It is never safe to assume that just because something is out there on the web that it is "nothing particularly bad"... (FML)
Fair enough. I expect the reactions here would have been worse though if the prevailing notion had been that [[Prototype]] is not mutable. ;-)
Andreas Rossberg wrote:
On 27 December 2012 06:38, David Herman <dherman at mozilla.com <mailto:dherman at mozilla.com>> wrote:
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren <annevk at annevk.nl <mailto:annevk at annevk.nl>> wrote: > It seems ES6 has __proto__ which also allows modifying [[Prototype]] > so presumably this is nothing particularly bad, although it is very > ugly :-( It is never safe to assume that just because something is out there on the web that it is "nothing particularly bad"... (FML)I'm not surprised to read this, though. Putting mutable proto into the language is far more than just regulating existing practice.
Your point may be general, but in case there's confusion about this "new" demand for mutable [[Prototype]]: nothing is new here. The adoptNode API is pretty old, a de-facto standard. The horse left the barn many years ago.
It is blessing it. That is a psychological factor that should not be underestimated. I fully expect to see significantly more code in the future that considers it normal to use this feature, and that no amount of evangelization can counter the legislation precedent.
Noted, and known. But then:
That is, if having it at all, I'd still think it much wiser to ban it to some Appendix.
What earthly good would that do?
On 27 December 2012 18:25, Brendan Eich <brendan at mozilla.com> wrote:
That is, if having it at all, I'd still think it much wiser to ban it to
some Appendix.
What earthly good would that do?
Marketing and psychology (as I said, being important). It would send a clear message that it is just ES adopting some bastard child because it has to for political reasons, but with no intention of ever making it a true bearer of its name. In other words, it isn't noble.
Andreas Rossberg wrote:
On 27 December 2012 18:25, Brendan Eich <brendan at mozilla.com <mailto:brendan at mozilla.com>> wrote:
That is, if having it at all, I'd still think it much wiser to ban it to some Appendix. What earthly good would that do?Marketing and psychology (as I said, being important). It would send a clear message that it is just ES adopting some bastard child because it has to for political reasons, but with no intention of ever making it a true bearer of its name. In other words, it isn't noble.
In one sense, whatever floats your boat.
In a more serious vein, we are at cross purposes with reality. Mutable proto just is. It is a de-facto standard. Doesn't mean we shouldn't fight [[Prototype]] changes where better methods of achieving desirable semantics exist. But calling mutable proto a bad thing, deprecating it, will not work, and therefore the attempt degrades the coin of TC39's realm: our attitude and opinion on normativity.
Self had writable parent slots. One can disagree with the design decision, but it's not unique to JS or uniquely evil. We swallowed this turd. No point whinging about it in appendices that either no one reads, or else people read and think less of the spec on that account.
On 28 December 2012 05:38, Brendan Eich <brendan at mozilla.com> wrote:
No point whinging about it in appendices that either no one reads, or else people read and think less of the spec on that account.
The fewer read about it the better, no? :)
Why would people think less about the spec?
I think it makes sense to separate out legacy features as normative optional, like it was the plan originally. Then implementations can still choose not to implement them when they can afford it, e.g. when JS is introduced into a new space where no such legacy exists.
Le 28/12/2012 10:29, Andreas Rossberg a écrit :
On 28 December 2012 05:38, Brendan Eich <brendan at mozilla.com <mailto:brendan at mozilla.com>> wrote:
No point whinging about it in appendices that either no one reads, or else people read and think less of the spec on that account.The fewer read about it the better, no? :)
Why would people think less about the spec?
I think it makes sense to separate out legacy features as normative optional, like it was the plan originally.
That's an interesting idea. What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). {define|lookup}{G|S}etter would fit well in this section.
Then implementations can still choose not to implement them when they can afford it, e.g. when JS is introduced into a new space where no such legacy exists.
A new web browser will need these legacy features, but I agree with non-browser implementation.
David Bruant wrote:
Le 28/12/2012 10:29, Andreas Rossberg a écrit :
On 28 December 2012 05:38, Brendan Eich <brendan at mozilla.com <mailto:brendan at mozilla.com>> wrote:
No point whinging about it in appendices that either no one reads, or else people read and think less of the spec on that account.The fewer read about it the better, no? :)
Why would people think less about the spec?
I think it makes sense to separate out legacy features as normative optional, like it was the plan originally. That's an interesting idea.
That idea, a retasking of Annex B, was rejected for reasons repeated below.
What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). {define|lookup}{G|S}etter would fit well in this section.
Those never made it into IE. Why include them? There's a bright line drawn by interop.
Then implementations can still choose not to implement them when they can afford it, e.g. when JS is introduced into a new space where no such legacy exists. A new web browser will need these legacy features, but I agree with non-browser implementation.
And as we discussed in accepting proto as normative not-optional:
-
Code gets ported, it is unlikely a new embedding will avoid proto if it becomes popular (Node.js is an example of how proto spread).
-
SES and other such systems are better off with normative mandatory, not normative optional.
Brendan Eich-3 wrote:
In a more serious vein, we are at cross purposes with reality. Mutable proto just is. It is a de-facto standard.
(...)
Self had writable parent slots. One can disagree with the design decision, but it's not unique to JS or uniquely evil.
I'm totally after "legalizing" proto (I already had few valid use cases
for that in important projects)
but maybe we should deprecate __proto__ (being a "property" is really
problematic) and standardize Object.setPrototypeOf? It would make things
much cleaner and safe.
Mariusz Nowak
Mariusz Nowak
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). {define|lookup}{G|S}etter would fit well in this section. Those never made it into IE. Why include them? There's a bright line drawn by interop.
I've seen Node.js code with it. Closed source so far. I don't think it'll be hard to find open source. ... googling ... * blog.james-carr.org/2010/07/19/defining-getters-and-setters-in-nodejs "you can define getters and setters using the ECMAScript5 syntax." and then shows an example with define{G|S}etter ahem
- nodemanual.org/0.6.9/nodejs_dev_guide/ECMA5_in_nodejs.html => Page titled "Using ECMA5 in Node.js"
define{G|S}etter Documented, but described as "This functions is a Mozilla extension and is not in ECMAScript 5.".
- fr.slideshare.net/the_undefined/nodejs-a-quick-tour => Slide 15 titled "ECMAScript 5" but shows an example with defineGetter
Oh boy! And these are just 3 of the 4 first results I see when searching "nodejs definegetter" Not only people do use it, but they recommand it and think it's part of ES5!
Searching in node_modules of a recent project, I see a couple of modules using defineGetter (I count own usages, not usage in their submodules): express, connect, formidable, nconf, pg, winston... Half of the modules I use freaking use it!
Special note for chai in which I have seen the "defineGetter" string, but because they removed it from their source :-) chaijs/chai/blob/master/History.md#012--2011-12-18
Apparently, define{G|S}etter really is a thing in Node.js. I really didn't have to dig deep...
Then implementations can still choose not to implement them when they can afford it, e.g. when JS is introduced into a new space where no such legacy exists. A new web browser will need these legacy features, but I agree with non-browser implementation.
And as we discussed in accepting proto as normative not-optional:
- Code gets ported, it is unlikely a new embedding will avoid proto if it becomes popular (Node.js is an example of how proto spread).
Add define{G|S}etter to the list I guess -_-#
On 28 December 2012 11:51, David Bruant <bruant.d at gmail.com> wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). {define|lookup}{G|S}etter would fit well in this section.
Those never made it into IE. Why include them? There's a bright line drawn by interop.
I've seen Node.js code with it.
That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends.
Le 28/12/2012 12:51, Andreas Rossberg a écrit :
On 28 December 2012 11:51, David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit : David Bruant wrote: What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). __{define|lookup}{G|S}etter__ would fit well in this section. Those never made it into IE. Why include them? There's a bright line drawn by interop. I've seen Node.js code with it.That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends.
Maybe the point that it was widely used in Node.js was never brought up? I discovered the first use of it a couple of weeks ago and I did the Google/node_module research I posted while writing the message.
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg <rossberg at google.com> wrote:
That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends.
proto is in all browsers, defineGetter is not.
Andreas Rossberg wrote:
On 28 December 2012 11:51, David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit : David Bruant wrote: What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). __{define|lookup}{G|S}etter__ would fit well in this section. Those never made it into IE. Why include them? There's a bright line drawn by interop. I've seen Node.js code with it.That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends.
defineGetter and friends have sane alternative, mutable proto hasn't?
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg <rossberg at google.com> wrote:
That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends. proto is in all browsers
What? It's not in IE10 last I heard.
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg <rossberg at google.com> wrote:
That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends. proto is in all browsers
What? It's not in IE10 and below last I heard.
On 28 December 2012 13:34, Herby Vojčík <herby at mailbox.sk> wrote:
Andreas Rossberg wrote:
That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends.
defineGetter and friends have sane alternative, mutable proto hasn't?
The argument for including proto has been existing practice, and AFAICS that applies to the others no less. The alternatives to proto are Object.create and Object.getPrototypeOf, which arguably cover the "sane" use cases.
On Dec 28, 2012, at 7:36, "David Bruant" <bruant.d at gmail.com> wrote:
Le 28/12/2012 13:32, Anne van Kesteren a ?crit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg <rossberg at google.com> wrote:
That's a good point, actually. I, for one, do not understand the criteria by which we chose to include
__proto__but not__defineGetter__and friends.__proto__is in all browsers What? It's not in IE10 and below last I heard
Correct. It seems to me that (modulo Opera? Haven't tested.) __proto__ and __defineGetter__ are supported in exactly the same places. What's the criteria?
What herby said is the reason. There's no compatibility burden for either those or proto because no version of IE implements either. However proto still has no alternative, while the accessor functions are fully replaced by ES5 features.
The only code you'll find in the wild that relies on the accessor functions is either extremely outdated and non-interoperable web code or lazy Node.js targeted code (I still don't get why these ever started showing up in Node.js code, but they do).
That is exactly the issue. As long as it was not expected in IE, it could not be assumed by the cross-browser web. However, mobile changed MS's tradeoffs. Mobile is currently a separate enough ecosystem, with IE a sufficiently minor player, that some cross-mobile-platform code assumes mutable proto. Consider it a loss of genetic diversity on the part of a herd that gets temporarily separated from the rest of its species. As a result, MS is considering adding mutable proto to future IE. At that point, it would become a standard, at least de facto. In that case, we're all better off codifying a semantics and having this standard be de jure.
If the history were different, the decision would be different.
On 28 December 2012 19:55, Mark S. Miller <erights at google.com> wrote:
That is exactly the issue. As long as it was not expected in IE, it could not be assumed by the cross-browser web. However, mobile changed MS's tradeoffs. Mobile is currently a separate enough ecosystem, with IE a sufficiently minor player, that some cross-mobile-platform code assumes mutable proto. Consider it a loss of genetic diversity on the part of a herd that gets temporarily separated from the rest of its species. As a result, MS is considering adding mutable proto to future IE. At that point, it would become a standard, at least de facto. In that case, we're all better off codifying a semantics and having this standard be de jure.
All understood, but what's the difference to defineGetter?
On Dec 28, 2012, at 11:48 AM, Andreas Rossberg <rossberg at google.com> wrote:
All understood, but what's the difference to defineGetter?
That MS does not appear to feel pressure to implement defineGetter but it does feel pressure to implement proto.
Mariusz Nowak wrote:
Brendan Eich-3 wrote:
In a more serious vein, we are at cross purposes with reality. Mutable proto just is. It is a de-facto standard.
(...)
Self had writable parent slots. One can disagree with the design decision, but it's not unique to JS or uniquely evil.
I'm totally after "legalizing" proto (I already had few valid use cases for that in important projects) but maybe we should deprecate
__proto__(being a "property" is really problematic) and standardizeObject.setPrototypeOf? It would make things much cleaner and safe.
No, for the reasons given here:
You have to read through the cited layers of text to get the full story.
Andreas Rossberg wrote:
On 28 December 2012 11:51, David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit : David Bruant wrote: What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). __{define|lookup}{G|S}etter__ would fit well in this section. Those never made it into IE. Why include them? There's a bright line drawn by interop. I've seen Node.js code with it.That's a good point, actually. I, for one, do not understand the criteria by which we chose to include proto but not defineGetter and friends.
It wasn't Node.js that drove that -- it was the "mobile (iOS WebKit first) web" that wanted proto due to libraries such as Zepto.
We have not heard equivalent demand from outfits such as Microsoft and Mozilla trying to gain mobile market share and interop with "mobile web" content. Not sure whether Opera ever weighed in.
proto is simply much more used than {define,lookup}{G,S}etter. Degree counts along with kind (turd or not :-P).
On Friday, December 28, 2012, David Bruant wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called "de facto standards"? It would indicate that it's part of the standard, but is a scar from history rather than a legit feature. An intro would explain what this is all about. It would be an interesting middleground between normal spec features (which people take for the Holy Graal) and appendices (which people will skip). {define|lookup}{G|S}etter would fit well in this section.
Those never made it into IE. Why include them? There's a bright line drawn by interop.
I've seen Node.js code with it. Closed source so far. I don't think it'll be hard to find open source. ... googling ...
blog.james-carr.org2010/07/19/defining-getters- and-setters-in-nodejs/blog.james-carr.org/2010/07/19/defining-getters-and-setters-in-nodejs "you can define getters and setters using the ECMAScript5 syntax." and then shows an example with define{G|S}etter ahem
nodemanual.org/0.6.9/**nodejs_dev_guide/ECMA5_in_**nodejs.htmlnodemanual.org/0.6.9/nodejs_dev_guide/ECMA5_in_nodejs.html => Page titled "Using ECMA5 in Node.js" define{G|S}etter Documented, but described as "This functions is a Mozilla extension and is not in ECMAScript 5.".
fr.slideshare.net/the_**undefined/nodejs-a-quick-tourfr.slideshare.net/the_undefined/nodejs-a-quick-tour => Slide 15 titled "ECMAScript 5" but shows an example with defineGetter
Oh boy! And these are just 3 of the 4 first results I see when searching "nodejs definegetter" Not only people do use it, but they recommand it and think it's part of ES5!
Searching in node_modules of a recent project, I see a couple of modules using defineGetter (I count own usages, not usage in their submodules): express, connect, formidable, nconf, pg, winston... Half of the modules I use freaking use it!
Special note for chai in which I have seen the "defineGetter" string, but because they removed it from their source :-) chaijs/** chai/blob/master/History.md#**012--2011-12-18chaijs/chai/blob/master/History.md#012--2011-12-18
Apparently, define{G|S}etter really is a thing in Node.js. I really didn't have to dig deep...
In the past I've engaged members of the node community about this and general response is: "______ didn't know about the ES5 APIs".
...which is certainly not a reason to include them in any part of the specification, annex or not
Rick Waldron wrote:
In the past I've engaged members of the node community about this and general response is: "______ didn't know about the ES5 APIs".
...which is certainly not a reason to include them in any part of the specification, annex or not
Right. So the full answer to Andreas and others' query about why proto normative mandatory in ES6 but no __define/lookup... is
-
proto much more used on the mobile (iOS WebKit-first) web, no equivalent interop pressure for __d/l.
-
ES5 is in all new/evergreened browsers and it has standard APIs supplanting __d/l but nothing for writing to proto.
Therefore proto gets standardized, __d/l do not. And I'm done typing __d/l!
I thought I'd give a heads up as over on www-dom at w3.org we're discussing two cases where we likely need to change the prototype chain of objects: document.open() and methods that do the equivalent of document.adoptNode() (including that method itself):
lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg143
It seems ES6 has proto which also allows modifying [[Prototype]] so presumably this is nothing particularly bad, although it is very ugly :-(