valentinium at gmail.com (2017-08-08T06:16:38.511Z)
> I haven't seen any suggestions for anything different than those three patterns; am I missing something? The draft I assembled does follow that pattern, but there was [another approach suggested](https://esdiscuss.org/topic/array-prototype-toobjectbyproperty-element-element-property#content-2) which is not concerned with entries and is instead similar to lodash’s keyBy method; it also permits supplying a target object rather than always creating a new object. --- _Gah, I always manage to screw up the recipient field on these threads._
valentinium at gmail.com (2017-08-08T06:16:03.347Z)
> I haven't seen any suggestions for anything different than those three patterns; am I missing something? The draft I assembled does follow that pattern, but there was [another approach suggested](https://esdiscuss.org/topic/array-prototype- toobjectbyproperty-element-element-property#content-2) which is not concerned with entries and is instead similar to lodash’s keyBy method; it also permits supplying a target object rather than always creating a new object. --- _Gah, I always manage to screw up the recipient field on these threads._
> I haven't seen any suggestions for anything different than those three patterns; am I missing something? The draft I assembled does follow that pattern, but there was [another approach suggested](https://esdiscuss.org/topic/array-prototype- toobjectbyproperty-element-element-property#content-2) which is not concerned with entries and is instead similar to lodash’s keyBy method; it also permits supplying a target object rather than always creating a new object. --- _Gah, I always manage to screw up the recipient field on these threads._ On Tue, Aug 8, 2017 at 2:13 AM, Darien Valentine <valentinium at gmail.com> wrote: > > I haven't seen any suggestions for anything different than those three > patterns; am I missing something? > > The draft I assembled does follow that pattern, but there was [another > approach suggested](https://esdiscuss.org/topic/array-prototype- > toobjectbyproperty-element-element-property#content-2) which is not > concerned with entries and is instead similar to lodash’s keyBy method; it > also permits supplying a target object rather than always creating a new > object. > > > On Tue, Aug 8, 2017 at 1:47 AM, Jordan Harband <ljharb at gmail.com> wrote: > >> If you have an object, you can already `Object.assign({}, object)`, or >> `Object.defineProperties({}, Object.getOwnPropertyDescriptors(object))`, >> with no intermediary, as of ES2015 and ES2017 respectively. >> >> The value here for something new would be `Object.fromEntries(Object.ent >> ries(object).map(…).filter(…))` or similar. >> >> I haven't seen any suggestions for anything different than those three >> patterns; am I missing something? >> >> On Mon, Aug 7, 2017 at 10:31 PM, Darien Valentine <valentinium at gmail.com> >> wrote: >> >>> > 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. >>>> >>> >>> >>> _______________________________________________ >>> 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/20170808/258f3ccc/attachment.html>