On Sat, Mar 15, 2014 at 7:38 PM, Jason Orendorff
<jason.orendo...@gmail.com>wrote:
> 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
