It's not that it's imperfect. It's that it's useless in the real world.
We can already do shallow testing of APIs. Reflect.support doesn't help there,
and in some ways (that I've outlined before) it is a regression.
```
if (!Array.prototype.includes) { ... }
if (!Reflect.supports("Array.prototype.includes")) { ... }
```
You also wouldn't do testing of syntax support at runtime, as you would
effectively be duplicating the code.
```
var myFunc;
if (Reflect.supports("TCO")) {
myFunc = recursiveImplementation;
} else {
myFunc = nonRecursiveImplementation;
// Why duplicate? You'd be saving yourself a lot of hassle by just
transpiling to this
}
```
What's the alternative? To send down a file that tests for support and then
sends it back to the server and then build the appropriate assets for that
browser?
No, that'd be absurdly slow, and now you've already delegated to using a build
tool.
- James Kyle
On Wed, Mar 25, 2015 at 1:44 PM, Kyle Simpson <get...@gmail.com> wrote:
> What this sub-discussion of CSS `supports(..)` is reinforcing is what I said
> earlier: a capability to do feature tests in a direct, efficient, and
> non-hacky manner is valuable to some/many uses and use-cases, even with the
> recognition that it doesn't have to *perfectly* support all conceivable
> uses/use-cases/tests.
> We should avoid a mindset that anything short of perfect isn't worth doing at
> all. Thankfully JS doesn't have such a design principle.
> A `Reflect.supports( Symbol.TCO )` test isn't perfect. It could accidentally
> or intentionally lie. But it *could* be better to some audiences than having
> no information. I personally would prefer to use it, even with its "risks",
> than trying a long recursive loop in a `try..catch` to imply if TCO was in
> effect.
> Nevertheless, it's the least important kind of test being advocated for here,
> even though it seems to be getting all the attention. If that kind of test is
> a bone of contention, it should be the easiest to drop/ignore.
> Moreover, to reduce the risk of bitrot on feature lookup tables (that
> `Symbol.TCO` would suffer), the `Reflect.supports( "(() => {})" )` test seems
> like it would be preferable to a `Reflect.supports( Symbol.arrowFunction )`
> type of test.
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
