On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola < dome...@domenicdenicola.com> 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. > I had similar questions a couple years ago and Allen advised that the easiest polyfill for such a mechanism is: function isConstructor(C) { try { new C(); return true; } catch (e) { return false; } } Additionally, at the July 2012 tc39 meeting I proposed (over breakfast) an ES7 "standard library module" that exported the abstract operations that are now defined in chapter 7 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-abstract-operations, the response was positive but it was far too early to have a serious discussion. Anyway, with that you'd just write: import { isConstructor } from "es-abstract"; Rick
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss