Caitlin Potter (2014-12-03T17:25:13.000Z)
> Have to be really careful adding things to Object.prototype, though — even when they’re non-enumerable, they can cause unexpected problems in code (code which probably ought to be using Object.create(null), but you know, doesn’t).


Being a Symbol rather than a String property key probably mitigates most of these problems, but I’m not positive about that.

Caitlin Potter

> On Dec 3, 2014, at 12:23 PM, Caitlin Potter <caitpotter88 at gmail.com> wrote:
> 
> It seems a bit late to add a default @@iterator to Object.prototype, but I guess it could work similar to Map.prototype.entries, if such a thing were to be added.
> 
> Have to be really careful adding things to Object.prototype, though — even when they’re non-enumerable, they can cause unexpected problems in code (code which probably ought to be using Object.create(null), but you know, doesn’t).
> 
> Caitlin Potter
> 
>> On Dec 3, 2014, at 12:07 PM, Mark Volkmann <r.mark.volkmann at gmail.com> wrote:
>> 
>> It seems the typical way to do this is:
>> 
>> Object.keys(myObj).forEach(key => {
>>  let value = myObj[key];
>>  // Do something with value and/or key.
>> });
>> 
>> I don't see a new way to do this in ES6.
>> 
>> Is it still being considered to add the methods "entries" and "values" to Object that return iterators?
>> 
>> -- 
>> R. Mark Volkmann
>> Object Computing, Inc.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
d at domenic.me (2014-12-08T21:41:52.415Z)
> Have to be really careful adding things to Object.prototype, though — even when they’re non-enumerable, they can cause unexpected problems in code (code which probably ought to be using Object.create(null), but you know, doesn’t).


Being a Symbol rather than a String property key probably mitigates most of these problems, but I’m not positive about that.