On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock <[email protected]>wrote:
> > On Feb 18, 2014, at 11:09 AM, Domenic Denicola wrote: > > > From: Allen Wirfs-Brock <[email protected]> > > > >> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
