The only concern I'd have with a symbol approach is that there are likely to be engine variances in the future - in the case of "let", knowing that the syntax is supported doesn't mean that ES6's semantics apply, it just means it won't throw a SyntaxError.
If that's the sole goal - detecting SyntaxErrors efficiently without using eval - then I think this is great - but what I'd really love to see is a path towards a built-in comprehensive way to determine semantic capabilities at runtime (as opposed to all the feature detection that devs/polyfills/shims/etc have to do now). On Sun, Mar 22, 2015 at 1:46 PM, Getify Solutions <[email protected]> wrote: > > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
