Standardizing __proto__

John-David Dalton john.david.dalton at
Fri Mar 18 19:27:55 PDT 2011

> But to get back to shaver's point: you are requiring a stylized, non-standard,
> popular-library-incompatible dialect of JS to be used from the start to work inside FuseJS's sandboxes, IIUC. Right?

Mike was getting OT onto the specifics and merits of sandboxed natives/FuseJS.
I was originally answering Allen's prompt for examples of other non
Array uses for __proto__.

> That's ok, not criticizing per se. Just noting it's yet another dialect. There are many such,
> some with translators that can handle the wrapping, even for primitives and literals, for you.

Non that provide the flexibility of extending prototypes of natives
directly without the risk of conflict and none
that **work** in browsers/environments from Safari 2.0.0 through IE9.

> Harmony is not about standardizing whatever hacks you needed to make your dialect work.

Thanks for the `hacks` comment.

> It's about core language features that complete and correct (by extension if not incompatible change)
> the incomplete and sometimes messy core language, even as of ES5.

I and others find __proto__ useful and gave a good use-case as prompted.
I am ok with __proto__'s eventual removal but as you stated earlier
there should be a replacement for use-cases.
The __proto__ property **is** a de facto standard and should be
standardized in some form to ensure compatibility, consistency, and

As mentioned before Array.create() is not enough, something like
Object.subclass() as previously proposed would be flexible for most
use-cases and
eliminate some of the perf/security concerns implementers have.


More information about the es-discuss mailing list