Allen Wirfs-Brock allen at
Fri Jun 13 11:20:22 PDT 2014

On Jun 13, 2014, at 11:02 AM, Boris Zbarsky wrote:

> On 6/13/14, 1:51 PM, Allen Wirfs-Brock wrote:
>> The object you return is an instance of the superclass and not of the subclass.
> Ah, right.
> So just to make sure, now that I think about it: in the @@create setup, where is the prototype of the object set?  What is the prototype of the thing @@create returns?


The default @@create is approximately:

Function.prototype[Symbol.create] = function(I) {
    return Object.create(this.prototype)

> Or put another way, is there really a difference, conceptually, between doing the "create an instance of the superclass and then change the prototype" thing and what @@create gives us?

No, except that changing the [[Prototype]] after the fact require a mutable [[Prototype]] and I can imaging that some object representations might not want to allow that.

>> The key thing that @@create is doing is separating determining the physical characteristics of an object (making it exotic, branding it, using a custom C struct as its representation, etc.) from logically initializing it at an appropriate place within some class hierarchy
> Looking at what's involved in object allocation in at least SpiderMonkey, the following pieces of data are required to be known at object creation time:
> 1)  The Realm to use.

normally that would be the same Realm as that of the @@@create method. But an @@create method could decide otherwise.

> 2)  Some metainformation about the exotic-or-not nature of the object,
>    its internal layout, etc.
> These are effectively not mutable in SpiderMonkey.

Right, that is essentially the primary motivation for @@create.  There are some low level characteristics of some objects that must be fixed when the storage of the object is allocated.

> In addition to those, it's good to have the prototype available at object-creation time as well, since later dynamic prototype mutation, while possible, leads to deoptimization in the JIT.  This may be a SpiderMonkey-specific issue, of course.



More information about the es-discuss mailing list