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 <[email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
