Standardizing __proto__

P T Withington ptw at pobox.com
Fri Mar 18 10:44:27 PDT 2011


You wouldn't need to reset the __proto__ of result if construction and initialization were separated, if the __proto__ of objects were only set by `new constructor`.  If `constructor.apply` did _not_ create a new object, only initialized it according to the arguments.

[The pattern you give is essentially how OpenLaszlo creates its class system, although we manually separate construction from initialization.]

Yes, I know that many constructors are already defined in the spec as creating a new object when called as a function.  That's unfortunate, IMO, since in general, ES has avoided "there's more than one way".

On 2011-03-18, at 13:00, Oliver Hunt wrote:

> 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.
> 
> --Oliver
> 
> 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 gmail.com> wrote:
>>> @Mike Shaver
>>> For other possible uses please check out:
>>> http://msdn.microsoft.com/en-us/scriptjunkie/gg278167
>>> https://github.com/jdalton/fusebox#readme
>> 
>> 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 mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list