Array.prototype.toObjectByProperty( element=>element.property )

[Alexander Jones]

`Map.fromIterable` takes an iterable of values, and a key function. Would a
`Map.prototype.toIterable` return only the values - that's already
`Map.prototype.values`? It feels like there is a symmetry issue here.
Perhaps this could be `Map.fromValues`?

Worth also remembering that compressing every possible use case down to an
absolute minimum has a cost if the resultant language has too many features
like this. I think `new Map(...kvps)` is a general solution that is
actually good enough for "indexing" purposes, and means that people only
have to internalise one method of construction via iterables.

That said, a helper function to allow constructing map-like objects from
arbitrary iterables would maybe be a bit more composable?

```js
// This works with Map, WeakMap, Immutable.Map, etc.
function* keyedBy(iterable, keyFn) {
  for (const element of iterable) {
    yield [keyFn(element), element];
  }
}

const allThePeople = [{name: "Joe", age: 24}, {name: "Barbara", age: 43},
...];

const index1 =
  new Map(keyedBy(allThePeople, _ => _.name));

// c.f.
const index2 =
  Map.fromValues(allThePeople, _ => _.name);
```

On 11 August 2017 at 10:26, Naveen Chawla <naveen.chwl at gmail.com> wrote:

> Of these, insertion ordering is the only one that may be compelling enough
> to me when I require that, to overcome the disadvantages. I never use the
> object prototype and I'm not convinced about the performance aspect. I
> reiterate though that `Map.fromIterable(allThePeople, person=>person.name)`
> is less verbose for the stated use case
>
> On Fri, 11 Aug 2017 at 11:55 Darien Valentine <valentinium at gmail.com>
> wrote:
>
>> @Alexander The idea of a generalized `map` function (etc, I’m guessing) is
>> appealing. From the way you talked about it, it sounds like there may
>> have been
>> past discussion on the topic. Are there any proposals for this or major
>> ideas
>> being batted around?
>>
>> > Why? What's the advantage? You lose at least the square bracket and dot
>> > notations for access, as disadvantages, and I'm not aware of any
>> advantages.
>> > If there aren't any that compensate for the disadvantages, then it's a
>> net
>> > negative
>>
>> @Naveen — a handful of things. Objects are indeed a perfectly reasonable
>> choice
>> for modeling kvp collections a lot of the time. On the other hand, because
>> objects in ES serve double duty as ways to model data and ways to "model
>> code",
>> they are not always ideal for the former case on account of the features
>> that
>> exist mainly to serve the second. Some examples of things that make maps
>> useful:
>> inherently iterable; no prototype chain access lookup; no collision with
>> `Object.prototype` property name when hashing by arbitrary keys;
>> potentially
>> more efficient for situations where keys are frequently removed;
>> `map.has()` is
>> more straightforward than having to consider whether you want `key in` or
>> `Object.hasOwnProperty` or which properties have been defined as
>> enumerable or
>> not; iteration order of entries is 1:1 with insertion order; and of
>> course, keys
>> can be of any type. Further, maps can be subclassed to constrain the
>> types that
>> they may hold or add other behaviors without needing to define custom
>> Proxies.
>>
>> Some general use cases: registries; hashing data where keys are from
>> external
>> input; kvp collections which are ordered; kvp collections which will be
>> subject
>> to later transformations; kvp collections to which new keys are
>> frequently added
>> or removed.
>>
>> While I hope that information is somewhat helpful, there are probably
>> much more
>> detailed resources online (including, I suspect, past discussions on this
>> list)
>> which could explain some of those things better or which include cases I
>> haven’t
>> thought of.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> 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/20170812/b99d8322/attachment.html>