Supporting feature tests directly

Jordan Harband ljharb at gmail.com
Sun Mar 22 21:17:20 UTC 2015


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 <getify at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150322/6b97d932/attachment.html>


More information about the es-discuss mailing list