Another way of thinking of IsConstructor is whether the function has an own prototype property or not. The only exception[*] there is bound functions where one would need to know if the [[TargetFunction]] IsConstructor or not.
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the IsConstructor will always return true which is really not what you want. If IsConstructor was changed to check for a .prototype instead proxies would behave more inline with ordinary objects. On Wed Jun 11 2014 at 10:24:49 AM, Domenic Denicola < [email protected]> wrote: > A variety of places in the spec use the new IsConstructor abstract > operation. In ES5, this test (essentially, "does the object implement the > [[Construct]] internal method") was restricted to the `new` operator. But > in ES6, it is used in implementing a large variety of built-in functions: > > - All Array methods > - All %TypedArray% methods > - All Promise methods (via NewPromiseCapability) > > (Note that there are two uses: arrays and typed arrays do alternative > logic for non-constructors; promises fail immediately. This inconsistency > might be a bug?) > > It seems to me that we should expose this primitive reflective operation > to users, instead of having all of these methods be able to detect > something that user code can't, and thus making them harder to explain or > polyfill. > > Alternately, if we don't think users should be doing this kind of > reflection, then we probably shouldn't be doing it ourselves. In which > case, figuring out an alternate path for the above methods would be > useful---perhaps they simply try to construct, and fail immediately if used > with a non-constructible object, instead of falling back. > > WDYT? > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
