On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:

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


Hi Allen, I agree with the rest, but I'm puzzled by your statement above.
ES6 is large. It has many pieces. Implementors cannot do everything first.
TC39 does not state a priority order among ES6 features so implementors
must. It has always been thus.




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

It is certainly valid and valuable for the community to provide feedback,
to help implementors prioritize. But it is still the implementors that must
make these priority order decisions.



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




-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140218/3ef0b2fc/attachment-0001.html>

On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
> It probably isn't appropriate for implementors to unilaterally decide
> whether or not this is a low priority feature.

Hi Allen, I agree with the rest, but I'm puzzled by your statement above.
ES6 is large. It has many pieces. Implementors cannot do everything first.
TC39 does not state a priority order among ES6 features so implementors
must. It has always been thus.

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

It is certainly valid and valuable for the community to provide feedback,
to help implementors prioritize. But it is still the implementors that must
make these priority order decisions.