Thanks Caitlin for actually putting this onto github! I wasn't aware of that process when I posted about this to the mailinglist. Asking again from last time: Should we have Type == Object check like Reflect.isExtensible?
-Tom On Sun, Mar 29, 2015 at 11:51 PM, Caitlin Potter <[email protected]> wrote: > **disclaimer** I know this has been brought up before, but bump :> > > People are experimenting with polyfilled class implementations, which > don’t all correctly throw when called as a function (no `new`). Eventually, > they’re likely to be disappointed that this isn’t legal, and might have to > undergo some serious pains to fix their applications. > > I notice that this is particularly problematic for AngularJS, because > classes are registered with an injector, which doesn’t know if it can > `[[Call]]` them or not. It will later on try to `[[Call]]` (depending on > how the class was registered with DI). It would be really great if we had a > way to determine if this was going to throw or not, other than looking at > the > stringified value of a function, so that these libraries could be updated > to accomodate new class behaviour without pains (try/catch or processing > Function.toString()) > > Some ideas: > > Reflect.isConstructor(fn) -> true if Class constructor, generator, or > legacy (and non-builtin) function syntactic form > Reflect.isCallable(fn) -> true for pretty much any function, except for > class constructors and a few builtins > > I know it’s way too late for ES6, but maybe some kind of fast-tracked > extension is in order? it should be pretty simple to implement these (and > SM and v8 have variations of these in the runtime anyways) > > _______________________________________________ > 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
