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

[Barret Furton]

Why not embrace `Array.prototype.reduce` instead of trying to abstract it
away?

```js
const identity = a => a

const toObject = (fk, fv = identity) =>
    (acc, curr) => (acc[fk(curr)] = fv(curr), acc)

const arr = [['a', '1'], ['b', '2'], ['c', '3']]

arr.map(a => [a[0], parseInt(a[1], 10)])
   .filter(a => a[0] !== 'c')
   .reduce(toObject(a => a[0]), {}) // { a: 1, b: 2 }
```

`reduce(toObject)` clearly communicates intent, and you can even provide an
existing object for merging.

On Sat, Aug 12, 2017 at 1:58 PM, Naveen Chawla <naveen.chwl at gmail.com>
wrote:

> My proposal was `Map.fromIterable(iterable, keyFromElement[,
> valueFromElement[, existingMap]])` so it's not meant to be symmetrical with
> `values` anyway. It was as an equivalent of `Object.fromIterable(iterable,
> keyFromElement[, valueFromElement[, existingObjectToUse]])` as a means to
> construct an object's keys and values from any iterable.
>
> I also was just thinking that both can perfectly coexist with
> `Array.prototype.toObject(keyFromElement[, valueFromElement])` which has
> the advantage of chain-ability after array transformation methods (like
> `filter` etc.). Array is such a fundamental construct that I would find
> myself using this one the most frequently
>
> On Sat, 12 Aug 2017 at 21:44 Alexander Jones <alex at weej.com> wrote:
>
>> `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
>>>
>>>
>>
> _______________________________________________
> 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/20170813/03776988/attachment.html>