Le 16/03/2014 00:45, Rick Waldron a écrit :
On Sat, Mar 15, 2014 at 7:38 PM, Jason Orendorff <[email protected] <mailto:[email protected]>> wrote:On Sat, Mar 15, 2014 at 5:19 PM, David Bruant <[email protected] <mailto:[email protected]>> 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.
Alright, convinced too. Thanks :-) David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
