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

[Darien Valentine]

> forced into it as an intermediary

Fortunately, no force is involved :)

T.J. Crowder indicated an intention to draft a proposal that I believe
aligns
with your ideas for converting objects to a single object by key with an
all-in-one map+compose method. It is not necessary for there to be only a
single
proposal in this space — aside from the fact that having diversity of ideas
on
the table is healthy, the two ideas do not seem to be in conflict with each
other.

> has worse performance

It’s a bit hard to speak about the performance of methods no engine has
implemented, but you might be overestimating the cost of
`Array.prototype.map`.

> The [key, value] pattern was originally introduced for Maps to allow
objects
> as keys [...]

You described earlier a previous unfamiliarity with the various `entries`
methods on collections. This might have contributed to an impression that
entries are a concern of Map specifically. While Map introduced entries, in
real-world code, I think it’s safe to say confidently that the frequency of
use
of `Object.entries` for iteration (as illustrated in Logan Smyth’s earlier
comment) and transformative operations (as mentioned in Jussi Kalliokoski’s
comment) dwarfs that of its use for map initialization.

> Yes unfortunately this doesn't apply to forEach, [...]

Are you referring to destructuring? It does:

    const obj = { apples: 2, bananas: 17, blueberries: 9 };

    const numberOfFruitsThatStartWithB = Object
      .entries(obj)
      .filter(([ key ]) => key.startsWith('b'))
      .reduce((acc, [ , value ]) => acc + value, 0);


On Tue, Aug 8, 2017 at 12:24 AM, Naveen Chawla <naveen.chwl at gmail.com>
wrote:

> On Tue, 8 Aug 2017 at 03:28 Logan Smyth <loganfsmyth at gmail.com> wrote:
>
>> > Object entries() is another strange case. Iterating over Object.keys
>> with key=> leaves myObject[key] to access the value, whereas iterating over
>> Object.entries with entry=> requires entry[0] and entry[1] which seems more
>> verbose for access, and less readable! So do you know why this was
>> introduced?
>>
>> Keep in mind that the pair syntax plays quite nicely with destructuring,
>> so assuming the iteration you're describing is something like
>>
>> ```
>> for (const key of Object.keys(myObject)) {
>>   const value = myObject[key];
>>
>>   // do stuff
>> }
>> ```
>>
>> I at least think it's much more readable to do
>>
>> ```
>> for (const [key, value] of Object.entries(myObject)) {
>>
>>   // do stuff
>> }
>> ```
>>
>>
> Yes unfortunately this doesn't apply to `forEach`, which I use much more
> frequently because it allows chaining after `map`, `filter`, `sort`,
> `concat` etc. and because it's slightly less verbose. I only use `for..of`
> when I need to break out of a loop, and which frankly I'll stop using
> once/if `takeWhile`/`skipWhile` are introduced.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170808/59ee1812/attachment-0001.html>