> So why not just add a sandbox, and ... means to catch error Other than the `import` / `export` thing I mentioned, for the exact reason why `eval(..)` and `new Function(..)` are not preferred (which roughly do the same thing)… A feature test that requires the entire parse/compile/execute cycle is, even a little bit, slower than a feature test that requires only the parser to answer the question at hand.
Since these tests are likely to happen in the critical path (page load), their speed is pretty important to be as optimal as possible. ------ I don't want or need a general means to try out a whole program to see if it compiles or not. Don't let the `eval`-looking form of the proposal mislead as to intention. Intention is only to, feature-by-feature, determine feature support where simple tests for identifiers is insufficient. For example, this is *not* intended to be possible: ```js let x; Reflect.supports( "let x;" ); // false -- dupe declaration! ``` That kind of test would require running in the context of the current lexical env, and would imply an entirely different level of integration with the program than intended. I don't need static errors like preventing duplicate declaration or anything of that nature. Even stuff like what `strict mode` would enforce are outside of the "scope" of what's being proposed. Only want to know if, in general, `let x;` could parse by the current engine. That's why `Reflect.supports( Symbol.letDecl )` would be an entirely sufficient option.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
