domenic at domenicdenicola.com (2014-06-20T19:23:18.687Z)
> Quick note: that isConstructor isn't really viable unless you plan on using > it with constructors that do not have side effects. The Proxy-based solution needs to be used in these cases. Now we just need to wait until Proxies are available everywhere! ;-)
> Quick note: that isConstructor isn't really viable unless you plan on using > it with constructors that do not have side effects. > > Rick The Proxy-based solution needs to be used in these cases. Now we just need to wait until Proxies are available everywhere! ;-) > > > On Wed, Jun 11, 2014 at 10:58 AM, Rick Waldron <waldron.rick at gmail.com <https://mail.mozilla.org/listinfo/es-discuss>> > wrote: > > >/ > />/ > />/ > />/ On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola < > />/ domenic at domenicdenicola.com <https://mail.mozilla.org/listinfo/es-discuss>> 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, <http://people.mozilla.org/%7Ejorendorff/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 > />/ > /> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140611/560bd448/attachment.html>