As far as I'm concerned, "most data arrays" — at least the ones you're speaking about — should actually be `Map`s. And their iterators (from, and to) yield key-value pairs. There is no syntax for a strict pair, so 2-element arrays have to do.
I'd still rather see some approach to generator expressions and/or iterator functions (like `map`, below) finally enter the standard somehow. ```js const allThePeople = [{name: "Joe", age: 24}, {name: "Barbara", age: 43}, ...]; // Python generator expression const myIndexByName = new Map([_.name, _] for _ of allThePeople); // map function to transform iterables you can argue about the argument order ;) const myIndexByName = new Map(map(allThePeople, _ => [_.name, _])); // equivalent to, but without the intermediate Array const myIndexByName = new Map(allThePeople.map(_ => [_.name, _])); ``` Alex On 10 August 2017 at 10:53, Naveen Chawla <naveen.c...@gmail.com> wrote: > I've yet to see any demonstration code use case for a `fromEntries` where > it would ever be preferable over a `fromIterable`, seeing as most back end > API JSON data arrays, and most data arrays in general for that matter, do > not come in the form of "entries". I would suggest that a `fromIterable` > with a `valueFromElement` callback, rather than being a "Swiss Army knife", > addresses the fundamental building block of an object, namely keys and > values, covering e.g. the "recentCountries" use case example code a few > posts back with minimal effort. > > On Thu, 10 Aug 2017 at 14:44 T.J. Crowder <tj.crow...@farsightsoftware.com> > wrote: > >> On Thu, Aug 10, 2017 at 9:49 AM, Naveen Chawla <naveen.c...@gmail.com> >> wrote: >> > >> > I think a property value callback is needed for completeness (not >> > easy to achieve the same functionality without it. >> >> In my view, a Swiss Army knife is not a good API function. (These are >> always, of course, judgement calls.) The `[key, value]` case can be >> addressed with Darien's `Object.fromEntries`. I've literally never needed >> that, but if one does, having something specific for it which fits into the >> `[key, value]` ecosystem makes sense to me. That's why I've said several >> times now that my suggestion and Darien's draft proposal are complementary, >> not conflicting/competing. In fact, it may be useful to combine them (but >> not the functions they define). >> >> Separately, I wonder how a second callback (in the case where it's a >> callback) compares in terms of performance and memory churn with returning >> `[key, value]` arrays. >> >> > Keying by a string property name should, in my view, be a separate >> > function >> >> I don't see the need. If it does exactly the same thing, just using a >> string directly rather than calling a function, then like `String#replace` >> I'm happy for it to handle that. Again, though, these are always judgement >> calls. >> >> -- T.J. Crowder >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss