Standardizing __proto__

Garrett Smith dhtmlkitchen at gmail.com
Mon Mar 21 11:24:46 PDT 2011


On 3/18/11, Kyle Simpson <getify at gmail.com> wrote:
> There's LOTS of sites out there that still (unfortunately) do unsafe
> overwriting/overloading of the native's prototypes. For instance, just a few
> months ago, I ran across a site that was creating a Array.prototype.push()
> implementation that was incompatible with the standard implementation. When
> I injected jQuery onto that page, jQuery failed to work because Sizzle
> relies on being able to call push() with multiple parameters (something the
> page's .push() didn't handle). And there are many, many other examples, like
> adding String.prototype.trim(), etc.
>
Yep. And JSON.parse, Function.prototype.apply, and others. Modifying
built-ins' prototypes is a powerful feature and modifying __proto__ is
even more powerful.

> The point? If everyone were in the habit of using sandboxable natives, like
> FuseBox provides, then that page could override it's version of Array all it
> wanted (even the native one), and my code, using Fuse.Array, would be
> perfectly safe.
>
The example you mention creates a problem that can be avoided by
instead using a feature test. It needs at least:

if(!Array.prototype.push) {

}

Just doing that would avoid the problem, thus obviating the need for a
workaround (with Sanboxes, etc).

I'm not arguing that it is wrong to standardize __proto__, just that
your example doesn't seem to support doing that.
-- 
Garrett


More information about the es-discuss mailing list