Standardizing __proto__

Oliver Hunt oliver at
Fri Mar 18 10:00:24 PDT 2011

I kind of dislike the proliferation of .create methods.  It's seems inelegant.  What if we had (use __proto__ for semantic description)

Object.subclass = function(constructor) {
    "use strict";
    function cons() {
        var result = constructor.apply(this, arguments);
        result.__proto__ = cons.prototype;
        return result;
    cons.prototype = Object.create(constructor.prototype);
    return cons;

This would provide a function that does that allows arbitrary "subclassing" of any function.  Obviously there are issues (call vs. construct behaviour, etc), but I think it's not too far off being a decent generic solution.


On Mar 18, 2011, at 9:46 AM, Mike Shaver wrote:

> On Fri, Mar 18, 2011 at 9:29 AM, John-David Dalton
> <john.david.dalton at> wrote:
>> @Mike Shaver
>> For other possible uses please check out:
> Those all look like they are needing custom-initialization, not
> arbitrary mutation at any point.  Would you agree?  For symmetry with
> Object.create, you might want Boolean.create, Date.create and so
> forth, but that's still initialization-time, and TBH I would be
> surprised if there were actually many collisions between libraries
> that augment those prototypes.
> Preserving (or adding to other engines) arbitrary prototype chain
> mutation in order to work around name collisions seems wrong to me.
> Mutable proto just happened to be the hack that worked (though so did
> iframes), and I can't really find anything other than Fuse that uses
> it on the web today.  The solution to name collisions is simple
> modules, IMO, not monkeypatching of the builtin prototype hierarchy.
> I think you can also achieve what you want with Harmony proxies, so
> you'll have that option in the next edition of ES.
> Mike
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list