<span id="mailbox-conversation"><div>It's not that it's imperfect. It's that it's useless in the real world.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>```</div>
<div>if (!Array.prototype.includes) { ... }</div>
<div>if (!Reflect.supports("Array.prototype.includes")) { ... }</div>
<div>```</div>
<div><br></div>
<div>You also wouldn't do testing of syntax support at runtime, as you would effectively be duplicating the code.</div>
<div><br></div>
<div>```</div>
<div>var myFunc;</div>
<div>if (Reflect.supports("TCO")) {</div>
<div>  myFunc = recursiveImplementation;</div>
<div>} else {</div>
<div>  myFunc = nonRecursiveImplementation;</div>
<div>  // Why duplicate? You'd be saving yourself a lot of hassle by just transpiling to this</div>
<div>}</div>
<div>```</div>
<div><br></div>
<div>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?</div>
<div><br></div>
<div>No, that'd be absurdly slow, and now you've already delegated to using a build tool.</div>
<div><br></div>
<div>- James Kyle</div></span><div class="mailbox_signature"><br></div>
<br><br><div class="gmail_quote"><p>On Wed, Mar 25, 2015 at 1:44 PM, Kyle Simpson <span dir="ltr"><<a href="mailto:getify@gmail.com" target="_blank">getify@gmail.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>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.
<br><br>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.
<br><br>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.
<br><br>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.
<br><br>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.
<br>_______________________________________________
<br>es-discuss mailing list
<br>es-discuss@mozilla.org
<br>https://mail.mozilla.org/listinfo/es-discuss
<br></p></blockquote></div><br>