Comments on “Making Built-in Objects Subclassable”

[Axel Rauschmayer]

A few more thoughts:

- This marks the end of prototypal inheritance in JavaScript (not complaining, just stating a fact). Putting @@create in constructors C makes a lot of sense, but it could, in principle, also be put into instance prototypes C.prototype. Then Object.create(proto) could use @@create to create the instance whose prototype is proto.

- I would love to have a @@postConstruct method (similar to @@create) that is invoked after all constructors are done with initialization. Use case: freeze an instance or make it non-extensible.

- Slide 24: marking objects as initialized in the root of a class hierarchy looks suspicious to me (the constructors are not done initializing, yet!). Doing it in something like @@postCreate might make more sense.

Axel

-- 

Dr. Axel Rauschmayer

[hidden email]

home: rauschma.de

twitter: twitter.com/rauschma

blog: 2ality.com

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Herby Vojčík]

Axel Rauschmayer wrote:
> A few more thoughts:
>
> - This marks the end of prototypal inheritance in JavaScript (not
> complaining, just stating a fact). Putting @@create in constructors C
> makes a lot of sense, but it could, in principle, also be put into
> instance prototypes C.prototype. Then Object.create(proto) could use
> @@create to create the instance whose prototype is proto.

The identifier create is probably used in lots of other places, so this
is non-starter, but if not, it could be simply reused, so that:

   Ctr.create(proto, [descriptors])

does

   newobj = Ctr[@@create]();
   newobj.__proto__ = proto;
   Object.defineProperties(newobj, descriptors);

It is semantically compatible with what Object.create does now.
In fact, if somewhere inside implementation of Object.create one would
use "this[@@create]" to create new instance, and it was moved to
Function.prototype, it could be used as is.

> Axel

Herby
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Herby Vojčík]

Herby Vojčík wrote:

>
>
> Axel Rauschmayer wrote:
>> A few more thoughts:
>>
>> - This marks the end of prototypal inheritance in JavaScript (not
>> complaining, just stating a fact). Putting @@create in constructors C
>> makes a lot of sense, but it could, in principle, also be put into
>> instance prototypes C.prototype. Then Object.create(proto) could use
>> @@create to create the instance whose prototype is proto.
>
> The identifier create is probably used in lots of other places, so this
> is non-starter, but if not, it could be simply reused, so that:
>
> Ctr.create(proto, [descriptors])
>
> does
>
> newobj = Ctr[@@create]();
> newobj.__proto__ = proto;
> Object.defineProperties(newobj, descriptors);

Sorry for replying to myself, but another possibility is to add proto
and descriptors parameters to IIRC parameterless @@create. Object.create
would thus just point to Object[@@create] and others could be create
similarly: Array[@@create](myprototype, mydescriptors);

> It is semantically compatible with what Object.create does now.
> In fact, if somewhere inside implementation of Object.create one would
> use "this[@@create]" to create new instance, and it was moved to
> Function.prototype, it could be used as is.
>
>> Axel
>
> Herby
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss