Subclassing ES6 objects with ES5 syntax.

Kevin Smith zenparsing at
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: <>

More information about the es-discuss mailing list