Re: ES6 iteration over object values
Le 15/03/2014 01:32, Brandon Benvie a écrit :
On 3/14/2014 5:16 PM, Mark Volkmann wrote:
Does ES6 add any new ways to iterate over the values in an object?
I've done a lot of searching, but haven't seen anything.
I'm wondering if there is something more elegant than this:
Object.keys(myObj).forEach(function (key) {
let obj = myObj[key];
// do something with obj
});
Not built in, but ES6 does provide a better story for this using
generators and for-of:
```js
// using a generator function
function* entries(obj) {
for (let key of Object.keys(obj)) {
yield [key, obj[key]];
}
}
// an alternative version using a generator expression
function entries(obj) {
return (for (key of Object.keys(obj)) [key, obj[key]]);
}
for (let [key, value] of entries(myObj)) {
// do something with key|value
}
```
Currently, there is no default Object.prototype.@@iterator, so
for-of'ing over an object throws a TypeError which isn't really a useful
default.
No having a default @@iterator also makes that Map({a:1, b:2}) throws
which is unfortunate.
Should what you just wrote be made the default
Object.prototype.@@iterator? It is compatible with the signature the Map
constructor expects too.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Initializer expression on for-in syntax subject
If we can get uglify and closure compiler to reject it it will go a long way toward making sure it doesn't crop up in the wild. On Mar 14, 2014 10:20 PM, Brendan Eich bren...@mozilla.org wrote: Peter van der Zee wrote: Which browsers currently don't accept this construct? I wasn't even aware that JSC didn't support it at some point. Did anyone say JSC lacked support? I think KJS followed ES3, and this was in the ES1 grammar, so I doubt it was never supported. Minifiers might rely on this construct. And perhaps some js1k entries, if that matters anything. Extremely doubtful. It doesn't save anything. A minifier cannot count on the loop iterating 0 times. Why is there a desire for banishment anyways? Only lack of consistency compared to not using the var keyword, This is only about the 'var' case. The initialiser in 'for (var x = y in z)' is due only to reuse of the wrong grammar nonterminal in ES1, based on JScript de-facto non-standard behavior. It is a wart and a pain to implement. We don't expect it to be hard to remove, unlike other warts, but we'll find out. or was there a bigger problem with this? The thread comes out of the blue to me so I probably missed a prior discussion :) ES6 revised the old grammar dating from ES1, breaking for(var x = y in z). That was intentional and discussed in past meetings and threads. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 iteration over object values
Le 15/03/2014 22:51, C. Scott Ananian a écrit :
It would be nicer to add an Object.entries() method that would return
that iterator.
Object.prototype.entries or Object.entries(obj)?
That would be less error prone than adding a default iterator to every
object.
The world has survived for-in and its weirdo unchangeable
enumerable+proto-climbing rules and that was error prone.
Now we can control enumerability of things that are added to the
prototype and the proposed default-but-still-overridable semantics is to
iterate only over own properties. It's less clear to me that the
proposed semantics is error prone.
The world has also evolved to a point where tooling can be written to
warn about non-overridden @@iterable property for a given class (I
feel like it is something TypeScript could do at least).
Even if error prone, I'd be interested to hear about arguments in the
sense that the risk outweighs the benefits. Iterable-by-default objects
is a nice battery included feature.
David
--scott
On Mar 15, 2014 7:42 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 15/03/2014 01:32, Brandon Benvie a écrit :
On 3/14/2014 5:16 PM, Mark Volkmann wrote:
Does ES6 add any new ways to iterate over the values in an
object?
I've done a lot of searching, but haven't seen anything.
I'm wondering if there is something more elegant than this:
Object.keys(myObj).forEach(function (key) {
let obj = myObj[key];
// do something with obj
});
Not built in, but ES6 does provide a better story for this
using generators and for-of:
```js
// using a generator function
function* entries(obj) {
for (let key of Object.keys(obj)) {
yield [key, obj[key]];
}
}
// an alternative version using a generator expression
function entries(obj) {
return (for (key of Object.keys(obj)) [key, obj[key]]);
}
for (let [key, value] of entries(myObj)) {
// do something with key|value
}
```
Currently, there is no default Object.prototype.@@iterator, so
for-of'ing over an object throws a TypeError which isn't really a
useful default.
No having a default @@iterator also makes that Map({a:1, b:2})
throws which is unfortunate.
Should what you just wrote be made the default
Object.prototype.@@iterator? It is compatible with the signature
the Map constructor expects too.
David
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Initializer expression on for-in syntax subject
I’ve landed the change to JSC to silently ignore the assignment in the non-strict “var ident =“ case, everything else is still an error so deconstruction and |of| enumeration will trigger a syntax error. —Oliver On Mar 15, 2014, at 2:01 PM, Brendan Eich bren...@mozilla.com wrote: Brendan Eich wrote: Peter van der Zee wrote: Which browsers currently don't accept this construct? I wasn't even aware that JSC didn't support it at some point. Did anyone say JSC lacked support? I think KJS followed ES3, and this was in the ES1 grammar, so I doubt it was never supported. Of course I was excluding the recent removal per draft ES6 that Oliver mentions in the root of this thread, JSC has been trying to kill off the initialiser expression in the for(in) statement -- sorry for confusion. Just to be clear, this is recent and per ES6, intentional. Hoping my site evang pals can get somewhere with battlefield.com. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 iteration over object values
On Sat, Mar 15, 2014 at 5:19 PM, David Bruant bruan...@gmail.com wrote:
Even if error prone, I'd be interested to hear about arguments in the sense
that the risk outweighs the benefits. Iterable-by-default objects is a nice
battery included feature.
I'm pretty sure es-discuss has been over this, but it doesn't hurt to restate:
1. This would mean that evolving any object in any API from *not*
having an @@iterator method to providing its own @@iterator method
would be a backward compatibility risk. Existing code might be using
the default @@iterator to enumerate the object's properties.
2. The default Object.prototype.@@iterator would not appear on
Object.create(null), so the one kind of object people would most want
to have this behavior (Objects specifically created for use as
dictionaries) would be the only kind of object that wouldn't have it.
A separate function would be better—you could apply it to anything
with properties.
Either reason alone would be enough, but to me #1 is a killer.
Platform evolution hazards are bad news. You get stuff like
Array.prototype.values being backed out of browsers, and then you get
stuff like @@unscopables.
I'd like to see an Object.entries method, and Object.values for
completeness. Same visibility rules as Object.keys.
for (let [k, v] of Object.entries(myObj)) {
// do something with k and v
}
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 iteration over object values
This thread's original question is answered by the Dict API ( https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#conclusionresolution-5 ). (more inline below) On Sat, Mar 15, 2014 at 6:19 PM, David Bruant bruan...@gmail.com wrote: Le 15/03/2014 22:51, C. Scott Ananian a écrit : It would be nicer to add an Object.entries() method that would return that iterator. Object.prototype.entries or Object.entries(obj)? That would be less error prone than adding a default iterator to every object. The world has survived for-in and its weirdo unchangeable enumerable+proto-climbing rules and that was error prone. Now we can control enumerability of things that are added to the prototype and the proposed default-but-still-overridable semantics is to iterate only over own properties. It's less clear to me that the proposed semantics is error prone. The world has also evolved to a point where tooling can be written to warn about non-overridden @@iterable property for a given class (I feel like it is something TypeScript could do at least). Even if error prone, I'd be interested to hear about arguments in the sense that the risk outweighs the benefits. An @@iterator on Object.prototype would result in Function, Boolean, Date, Error (and friends), and RegExp, having it in their prototype chain--none of these objects have anything to produce as an iterator value. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 iteration over object values
Jason Orendorff wrote:
I'd like to see an Object.entries method, and Object.values for
completeness. Same visibility rules as Object.keys.
for (let [k, v] of Object.entries(myObj)) {
// do something with k and v
}
+1, or +2 counting static methods :-).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 iteration over object values
On Sat, Mar 15, 2014 at 7:38 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Sat, Mar 15, 2014 at 5:19 PM, David Bruant bruan...@gmail.com wrote:
Even if error prone, I'd be interested to hear about arguments in the
sense
that the risk outweighs the benefits. Iterable-by-default objects is a
nice
battery included feature.
I'm pretty sure es-discuss has been over this, but it doesn't hurt to
restate:
1. This would mean that evolving any object in any API from *not*
having an @@iterator method to providing its own @@iterator method
would be a backward compatibility risk. Existing code might be using
the default @@iterator to enumerate the object's properties.
2. The default Object.prototype.@@iterator would not appear on
Object.create(null), so the one kind of object people would most want
to have this behavior (Objects specifically created for use as
dictionaries) would be the only kind of object that wouldn't have it.
A separate function would be better--you could apply it to anything
with properties.
Either reason alone would be enough, but to me #1 is a killer.
Platform evolution hazards are bad news. You get stuff like
Array.prototype.values being backed out of browsers, and then you get
stuff like @@unscopables.
I'd like to see an Object.entries method, and Object.values for
completeness. Same visibility rules as Object.keys.
for (let [k, v] of Object.entries(myObj)) {
// do something with k and v
}
Very enthusiastically agree--these would be excellent additions that balance
nicely with Dict (null __proto_ b/w keys, values, entries), along with all
of the builts-ins that received keys, values and entries on their
prototypes in ES6.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generalizable Function Modifier Syntax
Kevin Smith wrote:
async function af() {}
{ async af() { } }
This lines up with what Luke Hoban presented at the last TC39 meeting.
So far, so good (but not a done deal by any means, of course). The main
bone of contention is the use of ! in promises future-proposed syntax.
The hard part is arrow functions. One possibility would be to use
another cover grammar and place the modifier to the left of the arrow
function:
modifier [NoNewLine] Identifier =
modifier [NoNewLine] ArgumentList =
We could do this.
We could probably reuse some of the existing arrow function parsing
strategy to back up the input stream or transform the AST.
It smells, but we're used to it!
Another possibility would be to place the modifier to the right of the
argument list:
Identifier [NoNewLine] modifier = ...
ArgumentList [NoNewLine] modifier = ...
e.g.
x async= {}
(a, b, c) async= {}
This would be easier to parse, and would align with a potential
generator arrow:
x *= {}
(Presuming that we can give up on arrows with empty parameter lists.)
Bletch, and don't multiple risks unnecesasrily by entangling with
opposition to empty arrow param list elision.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 iteration over object values
On Sat, Mar 15, 2014 at 6:19 PM, David Bruant bruan...@gmail.com wrote:
Le 15/03/2014 22:51, C. Scott Ananian a écrit :
It would be nicer to add an Object.entries() method that would return that
iterator.
Object.prototype.entries or Object.entries(obj)?
`Object.entries(obj)` and `Object.values(obj)` (as suggested by Jason).
The linked resolution for `Dict`
(https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#conclusionresolution-5)
was less than clear, but generic `Dict.keys(obj)`,
`Dict.entries(obj)`, and `Dict.values(obj)` which can take arbitrary
objects (not just objects with no prototype) would be an okay
fallback. It leaves `Object.keys` an orphan, alas.
`Dict.prototype.entries.call(obj)` would be too long to be useful (but
I don't think that was being proposed).
```js
for (let [key, value] of Dict.entries(myObj)) {
// do something with key|value
}
```
That's not too bad. Shorter than `Object.entries`, even. (But I
personally don't see the point of `new Dict()` instead of
`Object.create(null)`, and prefer the `Object.*` names.)
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
