ES6 iteration over object values

Rick Waldron waldron.rick at
Sat Mar 15 16:45:00 PDT 2014

On Sat, Mar 15, 2014 at 7:38 PM, Jason Orendorff
<jason.orendorff at>wrote:

> On Sat, Mar 15, 2014 at 5:19 PM, David Bruant <bruant.d at> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list