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
