Elaboration on why the committee decided not to add an Object.map() method.

I have questions
1

I had proposed the idea previously to add an Object.mapEntries() method, and was told that the committee had already considered pretty much the same idea here, Object.map(), and did not pursue it.

The reasonings in the github repository are as follows:

Could anyone elaborate on this?

What is this "slippery slope"? Is TC39 worried about a map function being a slippery slope to adding a bunch of other object-helper methods to Object, such as .filer(), or .some() - similar to what we're doing with our other collection types in this proposal? Or does it mean something else?

Are there other reasons for not wanting such a function?

Thanks

2

I believe that’s what it means, yes - that if “map” were added, folks would request all the other array iteration methods to be added to Object as well.

1 Like
3

Alright. And what's the hesitation in adding the other array iteration methods to Object? I originally thought that TC39 just didn't want to redundantly add similar methods to all of the different collection types - until I saw that that's exactly what they're planning on doing with collection-methods proposal. Is TC39 trying to get us to use the Map class instead of plain objects as maps? Are they concerned these array-methods wouldn't be useful enough with objects? Some other reason?

1 Like
4

Collections tend to be a different set of use cases than objects.

I suspect the iterator helpers proposal (https://github.com/tc39/proposal-iterator-helpers) will mitigate the need for a lot of these kinds of APIs.

1 Like