> But AIUI the point of sandboxing is to keep different libraries from > stepping on each other's toes, and AFAICT such libraries use literals > (string, array, object and regexp) quite liberally.
Sandbox natives are used so FuseJS plays well with others while allowing the extension/modification of it's own set of natives. It's not about fix existing lib compatibility. > In Prototype all 4 are used. But they also extended global natives which causes conflicts. For example ExtJS adds Function#delay but so does PrototypeJS, and when used together they cause a JS errors. OR when MooTools/Prototype added Array#toJSON which broke native JSON for over a year and caused conflicts with YUI. > In jQuery all 4 are used and passing in a String object > where a string primitive is expected will fail because of explicit > typeof checks. Again not for jQuery. They have their own hurdles with an overly generic jQuery function, where attempting to check for isPlainObject is necessarily. > If you *do* control the code in question, you can just write your code > to use a namespace (Object.prototype.ns.method(), Extending the Object.prototype is a compatibility nightmare and extending natives causes third party script headaches. Sandboxed natives behave like natives and have the correct internal [[Class]] values so you can extend/customize without polluting the ones on the global. You can even create more than one of say the Array constructor as with fuse.Array and fuse.dom.NodeList (also an Array constructor but with DOM methods on it's prototype) And this **is** possible, in part, because of __proto__. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
