- From: <bugzilla@jessica.w3.org>
- Date: Fri, 25 Jan 2013 05:55:20 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 --- Comment #12 from Geoffrey Garen <ggaren@apple.com> --- In a way, I think this bug asks the wrong question. Our task isn't to pick a prototype -- it's to pick a set of observable properties. In a prototype-based language, the prototype is just one way to associate some properties with an object. This: { y: 0 } ^ { x: 0 } ^ { } is logically equivalent to this: { x: 0, y: 0 } If we want to logically sever the node's relationship to its old environment, and give it a new relationship to a new environment, we should be asking about all of its properties, and not just the ones belonging to its prototypes. If that's the goal, I think the best solution is to create a second wrapper. Direct references to the old wrapper would continue to see that wrapper's identity and custom properties (including those implemented by its prototypes), but new references returned by the DOM (e.g. via getElementById) would use a new wrapper, with a new identity and a new set of custom properties defined by its new prototypes. You might think that it's strange for a node's identity to change when it is adopted. But I think that's the most honest way to represent the operation you're describing. If adopting a node changes its very type, security identity, and so on, it's probably right to say that it's no longer equal to what it used to be. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Friday, 25 January 2013 05:55:21 UTC