Standardizing __proto__

John-David Dalton john.david.dalton at gmail.com
Fri Mar 18 12:12:51 PDT 2011


> I think Oliver's original formulation is more correct, but regardless this really would have to be specified using ES5 pseudo code.
>
> This is along the path of what I was calling a "generalized" solution to the problem and as such I think it needs deeper/longer
> consideration to be sure we have it right.  I think a single argument Array.create is safer  if we are looking for something that
> could be immediately implemented in order to start phasing out __proto__.  Having Array.create wouldn't stop also providing
> a more general solution such as the one below.

As a dev who actually uses __proto__ as a fallback for sandboxed
Arrays, I can tell you that Array.create() is **not** a quick,
suitable solution.
I support more than Array like String, RegExp, Function, Number, and Boolean.
I would stress, as it seems you keep circling back to Array.create(),
that Array.create() is not a fitting replacement for __proto__.
Not even in the short term.

I can see Oliver's proposal totally fitting __proto__'s use case, so I
would +1 his Object.subclass() over Array.create().
It would be great if solutions like Oliver's Object.subclass() were
discussed in the next meeting.


More information about the es-discuss mailing list