Supporting feature tests directly

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Mar 26 09:29:56 UTC 2015


> On Mar 22, 2015, at 2:00 AM, Kyle Simpson <getify at gmail.com> wrote:
> 
>> I think you're referring to the `eval` function?
> 
> Actually, I'm referring to proposing something new that would substitute for having to hack feature tests with `eval`.
> 
> These are the initial details of my idea, a `Reflect.supports(..)` method: https://gist.github.com/getify/1aac6cacec9cb6861706
> 
> Summary: `Reflect.supports( "(()=>{})" )` or `Reflect.supports( "let x" )` could test **just** for the ability to parse, as opposed to the compilation/execution that `eval(..)` does. It'd be much closer to `new Function(..)` except without the overhead of needing to actually produce the function object (and then have it be thrown away for GC).
> 
> This is inspired by https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API, where FF has a `Reflect.parse(..)` method that is somewhat like what I'm suggesting, except that for feature tests we don't need the parse tree, just a true/false of if it succeeded.
> 
> An alternate form would be `Reflect.supports( Symbol.arrowFunction )`, where the engine is just specifically saying "yes" I support that feature by recognizing it by its unique built-in symbol name.

I’m pretty skeptical about including this sort of feature testing feature as part of standard ECMAScript.  Here are some of the reasons:

ECMAScript doesn’t include the concept of language subsets/supersets (other than the Annex B features).  An conforming implementation of a Ecma TC39 standard is  expected to implement all of the features of current standard. Given that perspective, it isn’t clear why we would want to  provide a feature that was specificatlly design to enable non-conforming implementations.   test262 is TC39’s support for testing the standards conformance of an implementation. 

This sort  of feature testing is inherently a short term need. Within a few years, all implementations will support all major features, so work that does into incorporating specific feature detection into the ES standard (for example defining something like Symbol.arrowFunction) would be throw-away work that within in few years would just be legacy baggage that could never be removed from the language.  For example, I’m sure nobody today has a need to test Reflect.supports(Symbol.functionExpression) or Reflect.supports(Symbol.tryCatch).

On the other hand, a feature such as Reflect.parse which has other uses but which also has a potential applicability for feature detection seems reasonable.

Allen



More information about the es-discuss mailing list