Cross-frame symbols
It's unclear how we could possibly do this for anything but built-ins, and even there it's iffy. What if someone extends you builtin's prototype in one frame but not the other?
Anyhow, this all bottoms out at object identity. Functions are objects, and declaring identically named objects in different scripting contexts doesn't make the same object. To get there, you need some iron-clad notion of "sameness". Inventing it is fraught. My recommendation is to use frames a chunky barriers through which you do IPC, not fine-grained object boundaries over which you call local methods.
Alex Russell wrote:
It's unclear how we could possibly do this for anything but built-ins, and even there it's iffy. What if someone extends you builtin's prototype in one frame but not the other?
Anyhow, this all bottoms out at object identity. Functions are objects, and declaring identically named objects in different scripting contexts doesn't make the same object. To get there, you need some iron-clad notion of "sameness". Inventing it is fraught. My recommendation is to use frames a chunky barriers through which you do IPC, not fine-grained object boundaries over which you call local methods.
+1
If you do make a "small world network" of objects that span frame boundaries, then you're generally keeping it "all in the family" and can cope via copying, adding instanceOf or typeOf methods, etc.
I’m not sure that I don’t understand all the issues involved, but making symbols global just for cross-frame communication seems like an extreme measure. If that is possible, it would be great if we could fix cross-frame communication completely – also for instanceof, not just for symbols.
Does it make sense to view this as a serialization problem? One faces the same problem as in sending an object over a wire: If you create new Foo() at one end, you want that object to be instanceof Foo at the other end.
Axel