Supporting feature tests directly

Getify Solutions getify at gmail.com
Sun Mar 22 20:46:25 UTC 2015


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150322/ebb1f94e/attachment.html>


More information about the es-discuss mailing list