+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. Regards On Sun, Mar 22, 2015 at 1:00 AM, Kyle Simpson <[email protected]> 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: > https://gist.github.com/getify/1aac6cacec9cb6861706 > > 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 > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API, > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
