On 6/13/14, 1:51 PM, Allen Wirfs-Brock wrote:
> Unless, I misunderstand I don't think Jason is proposing eliminating @@create.

I had assumed he was...  I'm not sure I see the point if we're not doing 
that.

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

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?

> 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.
2)  Some metainformation about the exotic-or-not nature of the object,
     its internal layout, etc.

These are effectively not mutable in SpiderMonkey.

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.

-Boris

On 6/13/14, 1:51 PM, Allen Wirfs-Brock wrote:
> Unless, I misunderstand I don't think Jason is proposing eliminating @@create.

I had assumed he was...  I'm not sure I see the point if we're not doing 
that.

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

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?

> 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.
2.  Some metainformation about the exotic-or-not nature of the object,
     its internal layout, etc.

These are effectively not mutable in SpiderMonkey.

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.