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.dal...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
