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
featu
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,
whic
> On Mar 22, 2015, at 2:00 AM, Kyle Simpson 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.suppor
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 wrote:
> This exists:
This exists: http://test262.ecmascript.org
On Wed, Mar 25, 2015 at 8:12 PM, liorean 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 tests of pure inte
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 te
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 se
We're getting way afield with this whole transpilers thing. I'll indulge it for
just this response, then I'll return my focus on this thread to the issue at
hand: feature tests IN javascript.
> ...CSS. There was no way to do shallow testing so they added a way to do it.
As I have repeatedly sa
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. Why
>
> 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
> 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
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.
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
On Wed, Mar 25, 2015 at 1:17 PM, James Kyle 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 for "this is suppor
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 12:06 PM, Andrea Giammarchi
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.
>
> I wonder how reliable
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.
On Sun, Mar 22, 2015 at 3:59 AM, Andrea Giammarchi
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 share it as
> polyfill )
>
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 suppo
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 someth
> 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. Apo
> 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 effic
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, othe
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 g
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
wrote:
>
>
> On Sun, Mar 22
On Sun, Mar 22, 2015 at 4:47 PM Getify Solutions 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 thing)… A f
> 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
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 Synta
> 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 is
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" 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
> interact somehow)
>
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
htt
> ...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
+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
`Reflect
> 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/1aac6cacec9cb686170
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`, `const
I don’t think there are even documented best practices for ES6, yet (w.r.t.
switching between native ES6 and transpiled ES6). That’d be interesting, too.
> On 21 Mar 2015, at 21:28, Kyle Simpson wrote:
>
> Has there been any consideration or discussion for direct support of feature
> tests for
I think you're referring to the `eval` function?
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Kyle
Simpson
Sent: Sunday, March 22, 2015 05:28
To: es-discuss@mozilla.org
Subject: Supporting feature tests directly
Has there bee
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, and
39 matches
Mail list logo