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. On Fri, Oct 12, 2012 at 5:21 PM, Axel Rauschmayer <[email protected]> wrote: > 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 > > -- > Dr. Axel Rauschmayer > [email protected] > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
