Supporting feature tests directly

Косыч Дед kosich at gmail.com
Tue Mar 24 17:51:00 UTC 2015


What about checking tail call optimization support?
Imho, we need a possibility to verify engine supports it.
`eval`, `Function` and `Reflect.parse` wont work here.
So `Reflect.supports` looks more meaningful in this case.

On Mon, Mar 23, 2015 at 3:31 PM, Rick Waldron <waldron.rick at gmail.com>
wrote:

>
>
> On Sun, Mar 22, 2015 at 4:47 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.
>>
>
>
> The SpiderMonkey/Firefox Reflect.parse is non-standard, but may be a
> useful place to start.
>
> First, "import" the "reflect.jsm" component module:
>
>   Components.utils.import("resource://gre/modules/reflect.jsm");
>
> Then try this:
>
>   function isSyntaxSupported(syntax) {
>     try {
>       Reflect.parse(syntax);
>       return true;
>     } catch (_) {
>       return false;
>     }
>   }
>
>   [
>     "import foo from 'bar';",   // valid
>     "export var a = 1;",        // valid
>     "export default class {}",  // valid
>     "export class List {}",     // valid
>     "async function foo() {}",  // invalid
>     "let (x = 1) { x; }",       // invalid
>     "module Name {}",           // invalid
>   ].forEach(function(syntax) {
>     console.log("`%s` is %ssupported", syntax, isSyntaxSupported(syntax) ?
> "" : "un");
>   });
>
>
> Firefox 38.0a2 (2015-03-23):
>
> "`import foo from 'bar';` is supported"
> "`export var a = 1;` is supported"
> "`export default class {}` is unsupported"
> "`export class List {}` is unsupported"
> "`async function foo() {}` is unsupported"
> "`let (x = 1) { x; }` is supported"
> "`module Name {}` is unsupported"
>
>
>
> Rick
>
> _______________________________________________
> 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/20150324/73d23a56/attachment-0001.html>


More information about the es-discuss mailing list