Without the direct feature test API I'm suggesting (or something like it), how
will someone feature test the two new (proposed for ES7) `export` forms, for
example?
https://github.com/leebyron/ecmascript-more-export-from
I'm not strongly opposed to going the `Reflect.parse(..)` route for
On 3/26/15 at 8:51 AM, get...@gmail.com (Kyle Simpson) wrote:
As I mentioned near the beginning of this thread,
`Reflect.parse(..)` would generally suit the proposed use-case,
except it does a lot of extra work (creating and returning a
tree -- a value that then I'd be throwing away creating
doesn't yet solve my use cases, although I can't speak for Kyle.
It would not support my use-case. At least, in the sense that it's an
all-or-nothing which is counter to what I'm looking for. It's also going to be
way more processing intensive than just doing an `eval` / `Function` test,
Kyle Simpson wrote:
Totally disagree here. Anyone that's following the (Crockford) advice of not
using loops anymore and writing all recursion absolutely cares if such code can
be directly loaded into a browser or not.
LOL.
I don't think Crock was totally serious there... Let's get PTC
On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
For consistency sake I agree, but I come from a world where browsers also
exposed unofficially APIs so that, as James mentioned already,
`Array.prototype.includes` would have returned true and never worked.
On Sun, Mar 22, 2015 at 3:59 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
+1 to Kyle proposal, using eval or Function is not even an option in CSP
constrained environments ( unless the relative code is provided as SHA256,
then we need to agree on how such code should look like and
For consistency sake I agree, but I come from a world where browsers also
exposed unofficially APIs so that, as James mentioned already, `
Array.prototype.includes` would have returned true and never worked.
I wonder how reliable is `CSS.supports` not just in term of syntax, but
actual usability.
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
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
It's not that it's imperfect. It's that it's useless in the real world.
It's clear it's useless to you. It's not clear that it's useless to everyone.
In fact, I for one definitely find it useful. No sense in continuing to argue
over subjective opinion.
We can already do shallow testing of
The reason `@supports` works in CSS is because of the limited language
feature-set CSS has, but this wouldn't work in JavaScript.
To reuse the TCO example:
```
var supportsTCO = Reflect.supports('function recursive() { recursive() }');
```
Of course that will parse, and executing it
On Wed, Mar 25, 2015 at 1:17 PM, James Kyle m...@thejameskyle.com wrote:
The reason `@supports` works in CSS is because of the limited language
feature-set CSS has, but this wouldn't work in JavaScript.
No, it works because most of the time, whether or not something parses
is a sufficient proxy
It's not that it's imperfect. It's that it's useless in the real world.
...
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?
Its possible in the AMD approach. Idk though if its
The problem with that is you're still delegating to build tools and servers to
solve the entire problem. As you said previously you would not opt for the
pure-javascript solution:
```
if (Reflect.supports('TCO')) { /* recursive */ } else { /* not recursive */ }
```
So while I get the
I don't believe test262 can yet be run in a browser (only directly against
a browser engine), nor run in ES3 browsers (so that shimmed engines can be
tested) so that doesn't yet solve my use cases, although I can't speak for
Kyle.
On Wed, Mar 25, 2015 at 9:32 PM, James Kyle m...@thejameskyle.com
Re: shallow testing
Yes you've said that, but this is exactly what `@supports` is in CSS. There was
no way to do shallow testing so they added a way to do it.
Re: Bootstrapping
This is exactly my point, you're already using multiple builds and letting a
transpiler handle it for you.
As I see it, what might be more desireable than a straight shallow feature
test or feature support reporting feature would be an official versioned
test library, possibly including tests of pure internals, and a new
standard api for asking the engine for the results it gets for running a
certain
This exists: http://test262.ecmascript.org
On Wed, Mar 25, 2015 at 8:12 PM, liorean lior...@gmail.com wrote:
As I see it, what might be more desireable than a straight shallow feature
test or feature support reporting feature would be an official versioned
test library, possibly including
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
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,
That sounds like a horrible future to me.
IMO, this is the only remotely sensible go-forward plan to deal with the new
transpiler-reality we're in.
I for one hope that we're using the actual ES6+ code browser makers are
implementing rather than transpiling around it forever.
Ugh.
I think you missed my point.
Just as people make mistakes, sometimes JavaScript engines make mistakes in
their implementations (see: the engine might be lying to you), and there's
plenty of places where we need to catch these mistakes (see my jQuery example
from before). This is why
A lot of feature detection relies on shallow tests:
However, others need to test that features are properly supported by the
engine. This is because shallow testing does not cover engine quirks.
Of course, shallow tests are often totally sufficient, and I'm trying to have
the most
What about checking tail call optimization support?
Imho, we need a possibility to verify engine supports it.
`eval`, `Function` and `Reflect.parse` wont work here.
So `Reflect.supports` looks more meaningful in this case.
On Mon, Mar 23, 2015 at 3:31 PM, Rick Waldron waldron.r...@gmail.com
On Sun, Mar 22, 2015 at 4:47 PM Getify Solutions get...@gmail.com wrote:
So why not just add a sandbox, and ... means to catch error
Other than the `import` / `export` thing I mentioned, for the exact reason
why `eval(..)` and `new Function(..)` are not preferred (which roughly do
the same
So why not just add a sandbox, and let uncertificated codes run in the sandbox,
providing the external environment means to catch error (or interact somehow)
___
es-discuss mailing list
es-discuss@mozilla.org
+1 to Kyle proposal, using eval or Function is not even an option in CSP
constrained environments ( unless the relative code is provided as SHA256,
then we need to agree on how such code should look like and share it as
polyfill )
I'd also suggest `Reflect.isValidSyntax` as alternative to
The combination of the loader and realm APIs should give us that and, of
course, more.
On Mar 22, 2015 8:52 AM, Gary Guo nbdd0...@hotmail.com wrote:
So why not just add a sandbox, and let uncertificated codes run in the
sandbox, providing the external environment means to catch error (or
...using eval or Function is not even an option in CSP constrained
environments
...that's exactly what we'd like to know, if a generic syntax will break or
not.
Furthermore, there are things which are valid syntax which cannot be directly
`eval`'d or `Function`'d, such as `import` and
So why not just add a sandbox, and ... means to catch error
Other than the `import` / `export` thing I mentioned, for the exact reason
why `eval(..)` and `new Function(..)` are not preferred (which roughly do
the same thing)… A feature test that requires the entire
parse/compile/execute cycle
The only concern I'd have with a symbol approach is that there are likely
to be engine variances in the future - in the case of let, knowing that
the syntax is supported doesn't mean that ES6's semantics apply, it just
means it won't throw a SyntaxError.
If that's the sole goal - detecting
likely to be engine variances in the future
I hope you just mean like changes that ES7 might make to an ES6 feature. And I
hope those aren't syntactic as much as semantic. :)
If there was a change on syntax, I would assert that should be considered a
new feature with its own new test, even if
Has there been any consideration or discussion for direct support of feature
tests for ES7+ features/syntax? I'm thinking specifically of things which are
difficult or impossible to just simply test for, like via the existence of some
identifier.
I have an idea of what that could look like,
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:
In http://npmjs.com/make-generator-function,
https://www.npmjs.com/package/make-arrow-function, and the tests for
https://github.com/es-shims/RegExp.prototype.flags/blob/master/test/index.js#L6-L12,
I use `Function` eval to test for support of these things - one could do
the same with `let`,
35 matches
Mail list logo
