Hi there,
I was wondering if there were any plans to modify `arguments` to include
default parameters (e.g. changing it from a simpleParameterList) or to
include a new property that does allow iteration of all values available to
a function.
for example:
function foo( a, b = 2 ) {
Jacob Parker wrote:
In the context of only objects and classes, is this format no-go?
Without the } that closes a concise method body, there's a new problem
to-do with computed property names:
class C {
m() this._m
[Symbol.iterator]() {/*...*/}
}
We need a delimiter. Could use ;
Could the comma not be the delimiter, as I think works with arrow
functions, or is that more precedence issues?
On Wed, 25 Mar 2015 8:37 am Brendan Eich bren...@mozilla.org wrote:
Jacob Parker wrote:
In the context of only objects and classes, is this format no-go?
Without the } that closes
Jacob Parker wrote:
Could the comma not be the delimiter, as I think works with arrow
functions, or is that more precedence issues?
No precedence issue, due to AssignmentExpression (not Expression) being
the right-most non-terminal produced by the unbraced alternative for
ConciseBody.
Inline...
On Wed, Mar 25, 2015 at 12:25 AM Bob Myers r...@gol.com wrote:
Thanks Rick. Yes, I had been hoping to make the following work:
x = {a: 1};
y = {b: 2};
z = {x.a, b.y}; // {a: 1, b: 2}
This is not destructuring per se.
Of course, and that's not what I was exploring in attempting
On Wed, Mar 25, 2015 at 2:40 AM Robin Cafolla ro...@zombiemongoose.com
wrote:
Hi there,
I was wondering if there were any plans to modify `arguments` to include
default parameters (e.g. changing it from a simpleParameterList) or to
include a new property that does allow iteration of all
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
I think the main concern was:
Currently I can't see a way of getting default parameters as an iterable
object.
and indeed `arguments` is not the magic variable you are looking for.
However, you are inside your own defined function so either you don't
specify defaults, or you iterate over `[a,
bump.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
yes, they will work. hoisting of function initialization happens across the
whole module linkage graph before any module initialization code starts
executing. quoting @dherman.
there is one thing to keep in mind though: many edge cases cannot be transpile
into CJS, AMD, etc., the only format
I'm all for using Reflect, but looking at the API as listed on MDN, the
harmony-reflect github, or the spec, i don't see an obvious way of getting
the parameters.
If I understand you correctly (and this is not about parsing the parameter
definitions) then how about the following solution?
Well my use case is for something I can insert into an existing function,
in fact, a lot of functions, hopefully without manually listing the
arguments.
```js
function bar( parameters ) {
for ( var i = 0; i parameters.length; i++ ) {
// do something interesting with each parameter of
Andrea Giammarchi wrote:
I think the answer is still a static `[a, b]` as list of arguments to
apply, but I can see some lack of reflection capability ... or maybe
Reflect would solve this?
Yes, Reflect -- we want a mirror approach, not more magic object like
arguments or function.
/be
Sounds good to me and makes perfect sense. Robin?
On Wed, Mar 25, 2015 at 5:23 PM, Brendan Eich bren...@mozilla.org wrote:
Andrea Giammarchi wrote:
I think the answer is still a static `[a, b]` as list of arguments to
apply, but I can see some lack of reflection capability ... or maybe
But: you need to guard against other ways of reaching `finally`.
Why? I intended to always reach finally, and always close the iterator. Also,
simplicity ftw :-)
That’s not what all the other constructs in ES6 do: they only call
`return()` if iteration stops abruptly.
Only because
Given that redundant calls to `return()` don’t make a difference (h/t Bergi),
wouldn’t the iteration protocol be simpler if iterators were always closed
(versus only if iteration finishes abruptly). The code of generators wouldn’t
change (`finally` etc.), but “manually implemented” iterators
Good point, if it is about iteration, only `return()` needs to be propagated.
On 24 Mar 2015, at 23:35, Ron Buckton ron.buck...@microsoft.com wrote:
Is your goal to wrap a generator, as it seems you are propagating the
exception of the caller by calling iterator.throw(). However, you do not
Oops. Sorry about that.
On 25 March 2015 at 19:01, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
you keep replying to me only ... you really need to reply-all since I've
actually no idea ;-)
On Wed, Mar 25, 2015 at 5:53 PM, Robin Cafolla ro...@zombiemongoose.com
wrote:
I'm all for
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.
Axel Rauschmayer wrote:
Given that redundant calls to `return()` don’t make a difference (h/t Bergi)
I'm sorry, that was not 100% accurate. I only referred to `.return(x)`
returning {done:true, value:x} and `.throw(e)` being equivalent to
`throw e;` when the generator was never started or is
Would this be rectifiable with something like an unbound lambda type
syntax? You could even make an analogous equivalent for classes.
```js
// Lambda, unbound, ASI applies, same precedence as current arrow functions
() - foo;
(x) - bar(1, x);
x - bar(1, x); // same as previous
(...args) -
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
Right. Always closing is much simpler. Otherwise, you’d have to check
whether everything was exhausted or not.
This is by design, FWIW.
Which is OK, I’m more worried about generators behaving differently in reaction
to `return()` than, e.g., array iterators. With the latter, you can
Axel Rauschmayer schrieb:
wouldn’t the iteration protocol be simpler if iterators were always
closed (versus only if iteration finishes abruptly)?
Hm, I can't see much harm in that, it seemd to simplify the
implementation of iterators indeed. It changes the semantics from
| cleanup must be
Given that redundant calls to `return()` don’t make a difference (h/t Bergi)
I'm sorry, that was not 100% accurate.
Right, ignore that part of my email. My main argument is: “wouldn’t the
iteration protocol be simpler if iterators were always closed (versus only if
iteration finishes
Axel Rauschmayer wrote:
Right. Always closing is much simpler. Otherwise, you’d have to check
whether everything was exhausted or not.
This is by design, FWIW.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
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
38 matches
Mail list logo
