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?

yes. 

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.

+1

Allen

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

> 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?

yes. 

The default @@create is approximately:

```js
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.


> 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.

+1