Subclassing ES6 objects with ES5 syntax.

Kevin Smith zenparsing at gmail.com
Tue Apr 28 20:08:54 UTC 2015


>
> So, ES6 Promises reflect a specific set of design decisions, including a
> specific definition of "same type" that appears to exist solely for use by
> Promise.resolve.  All that design guarantees is that the object has an
> certain specific internal slot whose value is tested in a specific way by
> Promise.resolve.  It doesn't guarantee that the object is a well-promise or
> that it has any specific other characteristics that are expected of Foo
> objects. It's hard to extrapolate from that  specific design to the
> underlying intent of the designer.
>

I don't see any rational intent for the current design other than:

Only return x if x was **constructed** by C.

The current semantic is:

Only return x if x was constructed by C, or any code with a reference to C
arbitrarily chose that it should appear to have been constructed by C.

Allowing an object to pass a nominal type test for a constructor, where the
object was not initialized by that constructor seems bad.

What is the use case for third argument to Reflect.construct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150428/ffd3ed47/attachment.html>


More information about the es-discuss mailing list