> Not all objects are used as maps, and when using with map we often use
`Object.create(null)`, so adding to prototype is definitely a bad idea.

- Much like we're forced to invoke the prototype directly like (in
functions & NodeLists) `Array.prototype.slice.call(arguments)`, an argument
could be made that one should need invoke
`Object.prototype.map.call(objWithoutPrototype, mapFn)`.
- My main issue with static methods on the object is the lack of
consistency with the array format. But given that we already have
`Object.keys` and `Object.values`, there's already precedent for this (plus
the argument about breaking legacy frameworks). Note that this methods
should be on the `Map.prototype` at least (given
`Map.prototype.keys/values` exist), since this argument doesn't apply in
that case.

> As for whether we should make them static methods of Object, I personally
don't think this is very useful. Using a for-in loop is enough in my
opinion.

For-in loops result in unnecessary verbosity, specially in codebases that
optimize for readability. Comparing something like:

```
const normalizedGrey = colors
  .map(c => (c.red + c.green + c.blue) / 3)
  .filter(g => g < someThreshold)
  .map(g => (g - min) / (max - min));
```
vs

```
let normalizedGrey = {};
for (var color in colors) {
  let c = colors[color];
  let g = (c.red + c.green + c.blue) / 3;
  if (g < someThreshold) {
    normalizedGrey[color] = (g - min) / (max - min);
  }
}
```
The latter has more lines/bytes and is harder to read.

On Sat, Jan 30, 2016 at 11:02 AM, Gary Guo <nbdd0121 at hotmail.com> wrote:

> Not all objects are used as maps, and when using with map we often use
> `Object.create(null)`, so adding to prototype is definitely a bad idea. As
> for whether we should make them static methods of Object, I personally
> don't think this is very useful. Using a for-in loop is enough in my
> opinion.
>
> ------------------------------
> From: kaustubh.karkare at gmail.com
> Date: Fri, 29 Jan 2016 18:07:30 -0500
> Subject: Additional methods for Objects (like Arrays)
> To: es-discuss at mozilla.org
>
>
> I have recently come to feel the need for Object.map, which is like
> Array.map,
> except that it receive keys instead of indices.
>
> Object.prototype.map = function(mapFn, context) {
>   return Object.keys(this)
>     .reduce(function(result, key) {
>       result[key] = mapFn.call(context, this[key], key, this);
>       return result;
>     }, {});
> };
>
> Without this, I frequently do the exact same thing as the above manually,
> which leads to unnecessary code duplication.
>
> Given that, it might make sense to match other methods from Array.prototype
>
> Object.map
> Object.filter
> Object.every
> Object.some
> Object.reduce
> Object.find
> Object.findKey // like Array.findIndex
>
> Note that wherever applicable, the ordering is non-deterministic.
>
>
> _______________________________________________ es-discuss mailing list
> es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160130/4426f397/attachment.html>

> Not all objects are used as maps, and when using with map we often use `Object.create(null)`, so adding to prototype is definitely a bad idea.

- Much like we're forced to invoke the prototype directly like (in functions & NodeLists) `Array.prototype.slice.call(arguments)`, an argument could be made that one should need invoke `Object.prototype.map.call(objWithoutPrototype, mapFn)`.
- My main issue with static methods on the object is the lack of consistency with the array format. But given that we already have `Object.keys` and `Object.values`, there's already precedent for this (plus the argument about breaking legacy frameworks). Note that this methods should be on the `Map.prototype` at least (given `Map.prototype.keys/values` exist), since this argument doesn't apply in that case.

> As for whether we should make them static methods of Object, I personally don't think this is very useful. Using a for-in loop is enough in my opinion.

For-in loops result in unnecessary verbosity, specially in codebases that
optimize for readability. Comparing something like:

```
const normalizedGrey = colors
  .map(c => (c.red + c.green + c.blue) / 3)
  .filter(g => g < someThreshold)
  .map(g => (g - min) / (max - min));
```
vs

```
let normalizedGrey = {};
for (var color in colors) {
  let c = colors[color];
  let g = (c.red + c.green + c.blue) / 3;
  if (g < someThreshold) {
    normalizedGrey[color] = (g - min) / (max - min);
  }
}
```
The latter has more lines/bytes and is harder to read.