> On Mar 22, 2015, at 2:00 AM, Kyle Simpson <get...@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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
