> 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.c...@gmail.com> wrote: > On Tue, 8 Aug 2017 at 03:28 Logan Smyth <loganfsm...@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. >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss