Supporting feature tests directly

Andrea Giammarchi andrea.giammarchi at
Sun Mar 22 10:59:30 UTC 2015

+1 to Kyle proposal, using eval or Function is not even an option in CSP
constrained environments ( unless the relative code is provided as SHA256,
then we need to agree on how such code should look like and share it as
polyfill )

I'd also suggest `Reflect.isValidSyntax` as alternative to
`Reflect.supports` 'cause it's less misleading when it comes to figure out
APIs support and their implementation.

After all, that's exactly what we'd like to know, if a generic syntax will
break or not.


On Sun, Mar 22, 2015 at 1:00 AM, Kyle Simpson <getify at> wrote:

> > I think you're referring to the `eval` function?
> Actually, I'm referring to proposing something new that would substitute
> for having to hack feature tests with `eval`.
> These are the initial details of my idea, a `Reflect.supports(..)` method:
> Summary: `Reflect.supports( "(()=>{})" )` or `Reflect.supports( "let x" )`
> could test **just** for the ability to parse, as opposed to the
> compilation/execution that `eval(..)` does. It'd be much closer to `new
> Function(..)` except without the overhead of needing to actually produce
> the function object (and then have it be thrown away for GC).
> This is inspired by
> where FF has a `Reflect.parse(..)` method that is somewhat like what I'm
> suggesting, except that for feature tests we don't need the parse tree,
> just a true/false of if it succeeded.
> An alternate form would be `Reflect.supports( Symbol.arrowFunction )`,
> where the engine is just specifically saying "yes" I support that feature
> by recognizing it by its unique built-in symbol name.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list