Rick Waldron (2014-03-15T23:37:48.000Z)
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 <bruant.d at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140315/599148ec/attachment-0001.html>
domenic at domenicdenicola.com (2014-03-26T23:08:11.471Z)
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 <bruant.d at gmail.com> wrote:

>>  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.