Taking steps to make sure new features can be feature tested is A Good Thing®
but relying on something being set that says "I support X" probably isn't the
best path to take.
A lot of feature detection relies on shallow tests:
i.e. `if (!Array.prototype.includes) { ...`
However, others need to test that features are properly supported by the
engine. This is because shallow testing does not cover engine quirks.
i.e.
https://github.com/jquery/jquery/blob/7602dc708dc6d9d0ae9982aadb9fa4615a9c49fa/external/sizzle/dist/sizzle.js#L165-L191
So while I agree that feature support should be detectable as much as possible,
relying on something like `Reflect.supports(...)` isn't any more useful than
shallow feature detection (the engine might be lying to you).
TCO is one of the places where it is difficult to test for. However, it's a
pretty rare that you would want to.
i.e.
```
var maybeRecursive;
if (Reflect.support('TCO')) {
maybeRecursive = function(n) {
n < 1000000 ? maybeRecursive(n++) : n;
};
} else {
maybeRecursive = function(n) {
while (n < 1000000) {
n++;
}
return n;
}
}
recursive(0);
```
In this case you would just write the second. This is also true for most syntax
features: you wouldn't use feature detection, you would simply transpile your
code down to the lowest level of support you need it to have.
Again, definitely a good idea to ensure feature support is detectable. Luckily
this is fairly well covered by the tc39 process since a polyfill is required as
early as stage 1.
- James Kyle
On Tuesday, Mar 24, 2015 at 3:44 PM, Kyle Simpson <[email protected]>, wrote:
I should stress that while my original proposal (linked earlier in thread)
mentions some of the "hard" ES6 cases (like TCO), my focus is not on creating
feature tests for ES6. ES6 has sailed. Any feature we could possibly conceive
here is quite unlikely to land in a browser before that browser gets all (or at
least most) of the ES6 stuff that one might be wanting to test for.
My goal is for us to stop adding features to JS that aren't practically feature
testable. I would strenuously desire to have something like
`Reflect.supports(..)` (of whatever bikeshedded form) in ES2016 along with any
new conceived features. That goes a thousand times more if we invent new syntax
(we likely are) or new untestable semantics (like TCO).
Of course, if we had `Reflect.supports(..)` now, it'd be amazingly helpful in
detecting TCO, which I would dearly love. But that's not the goal. I don't
think we need to muddy the waters about what the ES6 feature tests would be. At
least not for now.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
