Last thread:
https://esdiscuss.org/topic/add-reflect-isconstructor-and-reflect-iscallable.
Died off again.
There's no issue with ES7 vs. ES6 without a spec, and having a draft
spec at the right stage (1 for flagged implementation?) is the thing.
Who will do it?
/be
Caitlin Potter 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
