Erik Arvidsson erik.arvidsson at
Wed Jun 11 07:48:07 PDT 2014

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 <
domenic at> 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.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list