Without the direct feature test API I'm suggesting (or something like it), how will someone feature test the two new (proposed for ES7) `export` forms, for example?
https://github.com/leebyron/ecmascript-more-export-from I'm not strongly opposed to going the `Reflect.parse(..)` route for feature-testing (certainly more preferable than `eval` / `Function`), except I'm concerned that: 1. it will offer no reasonable path in the future for answering the "hard" tests, like TCO would have been. Would `Reflect.parse( Symbol.TCO )` be too janky of a hack for such things? 2. engines won't be able to tell (static analysis?) that the parse tree isn't needed and not wasting that memory for GC to clean up. The advantage of an API that doesn't return anything but `true` / `false` means the engine knows it doesn't need to keep the tree around and send it into JS-land. I don't know if there's any internal processing benefits, but it certainly seems there's memory benefits. > I don't see a real need for high performance in these tests High performance? No. But, if these feature tests slow down an app in the most critical of its critical paths (the initial load) to the point where people can't use the feature tests in the way I've proposed, then the "solution" is moot. I *could* load up an entire parser written in JS and use it to parse syntax strings. That's *a* solution. But it's not a *viable* solution because it's way too slow for the purpose of feature tests during a split load. So it should be noted that the proposal does imply that whatever solution we come up with, it has to be reasonable in performance (certainly much better than `eval` / `Function` or a full JS parser loaded separately). _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
