On Thu, Mar 28, 2013 at 2:37 AM, Norbert Lindenberg <[email protected]> wrote: >> [2013-03-27 14:38:40] <till> How about we initialize all builtins in the >> self-hosting global, as we do now, then, during interpretation of the >> self-hosting script itself, install the self-hosted methods on those >> builtins, and then use those objects as, well, prototypes we clone into all >> other compartments upon creation? >> [2013-03-27 14:38:51] <Waldo> the right terminology for the splitting is >> cloning versus wrapping -- if I keep that in mind firmly I won't get confused >> [2013-03-27 14:40:05] <till> Crucially, we'd only clone those methods >> installed on builtins, no others >> [2013-03-27 14:40:13] <Waldo> that could be interesting as well >> [2013-03-27 14:40:36] * Waldo tries to think about how to break that, or >> something >> [2013-03-27 14:41:15] <till> It might be desirable to explicitly clone some >> helper functions that should deal with per-compartment data. Seems doable, >> though. > > That would cover functions such as getInternals, InitializeCollator, > InitializeNumberFormat, InitializeDateTimeFormat in Intl.js, I assume. What > happens when these then call other functions that haven't been cloned?
If a function is cloned, it invokes all other self-hosted functions from within the client compartment. Meaning that invoking them works as it does now. If you want to modify per-compartment state from within those functions, they must be cloned, too. As an author of self-hosted code, one would have to be careful not to change state from inside non-cloned functions, as that would mean changing state within the self-hosting compartment. Maybe we could guard against that, somehow. _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
