Standardizing __proto__

John-David Dalton john.david.dalton at
Fri Mar 18 17:11:17 PDT 2011

> 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__.

More information about the es-discuss mailing list