On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:

> From: Allen Wirfs-Brock <allen at wirfs-brock.com>
> 
>> No, even if you removed the checks in Map and Promise and WeakMap that prevent them from trying to initialize an object that lacks the appropriate internal slots it still wouldn't work because obj does not have the internal slots necessary to support the built-in operations upon those objects and implementations commonly implement such objects in a manner that prevents the dynamic addition of such slots.
> 
>> The whole purpose of @@create is to allow implementations to allocate prior to invoking a constructor the correctly shaped object for built-ins.
> 
> Well, but you could just move the internal slot initialization into the constructor itself (as Scott has done in his es6-shim promises). Unlike e.g. `Array`, the objects returned by `Promise[@@create]` are not exotic objects; they are simply normal objects with some internal slots initialized. So the movement of code between `@@create` and the constructor does not impact very much.

No, the whole point of @@create was to avoid that.  In fact, initially I tried to specify something like that and implementors objected.  The problem is that some implementations want to allocate different shaped object records for built-ins with specific internal slots and they can't dynamically change the size of the a normal object record that lacks those slots.  It doesn't have anything to do with exotic objectness (which is about the behavior of the internal MOP methods) but instead about the memory layout of the objects.

This was was discussed in detail 2+ years ago and there was consensus that @@create was the way to go. Now it's time to implement it. 

It probably isn't appropriate for implementors to unilaterally decide whether or not this is a low priority feature.  However, I can understand how they might reach that conclusion if application and framework authors aren't vocal if they consider it to be a high priority feature.

The reason I championed this capability was because I had heard years of complaining from JS developers about not being able to "subclass" Array, Date, etc.

Allen

On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote:

> Well, but you could just move the internal slot initialization into the constructor itself (as Scott has done in his es6-shim promises). Unlike e.g. `Array`, the objects returned by `Promise[@@create]` are not exotic objects; they are simply normal objects with some internal slots initialized. So the movement of code between `@@create` and the constructor does not impact very much.

No, the whole point of @@create was to avoid that.  In fact, initially I tried to specify something like that and implementors objected.  The problem is that some implementations want to allocate different shaped object records for built-ins with specific internal slots and they can't dynamically change the size of the a normal object record that lacks those slots.  It doesn't have anything to do with exotic objectness (which is about the behavior of the internal MOP methods) but instead about the memory layout of the objects.

This was was discussed in detail 2+ years ago and there was consensus that @@create was the way to go. Now it's time to implement it. 

It probably isn't appropriate for implementors to unilaterally decide whether or not this is a low priority feature.  However, I can understand how they might reach that conclusion if application and framework authors aren't vocal if they consider it to be a high priority feature.

The reason I championed this capability was because I had heard years of complaining from JS developers about not being able to "subclass" Array, Date, etc.