My proposal was `Map.fromIterable(iterable, keyFromElement[,
valueFromElement[, existingMap]])` so it's not meant to be symmetrical with
`values` anyway. It was as an equivalent of `Object.fromIterable(iterable,
keyFromElement[, valueFromElement[, existingObjectToUse]])` as a means to
construct an object's keys and values from any iterable.
I also was just thinking that both can perfectly coexist with
`Array.prototype.toObject(keyFromElement[, valueFromElement])` which has
the advantage of chain-ability after array transformation methods (like
`filter` etc.). Array is such a fundamental construct that I would find
myself using this one the most frequently
On Sat, 12 Aug 2017 at 21:44 Alexander Jones <a...@weej.com> wrote:
> `Map.fromIterable` takes an iterable of values, and a key function. Would
> a `Map.prototype.toIterable` return only the values - that's already
> `Map.prototype.values`? It feels like there is a symmetry issue here.
> Perhaps this could be `Map.fromValues`?
>
> Worth also remembering that compressing every possible use case down to an
> absolute minimum has a cost if the resultant language has too many features
> like this. I think `new Map(...kvps)` is a general solution that is
> actually good enough for "indexing" purposes, and means that people only
> have to internalise one method of construction via iterables.
>
> That said, a helper function to allow constructing map-like objects from
> arbitrary iterables would maybe be a bit more composable?
>
> ```js
> // This works with Map, WeakMap, Immutable.Map, etc.
> function* keyedBy(iterable, keyFn) {
> for (const element of iterable) {
> yield [keyFn(element), element];
> }
> }
>
> const allThePeople = [{name: "Joe", age: 24}, {name: "Barbara", age: 43},
> ...];
>
> const index1 =
> new Map(keyedBy(allThePeople, _ => _.name));
>
> // c.f.
> const index2 =
> Map.fromValues(allThePeople, _ => _.name);
> ```
>
> On 11 August 2017 at 10:26, Naveen Chawla <naveen.c...@gmail.com> wrote:
>
>> Of these, insertion ordering is the only one that may be compelling
>> enough to me when I require that, to overcome the disadvantages. I never
>> use the object prototype and I'm not convinced about the performance
>> aspect. I reiterate though that `Map.fromIterable(allThePeople, person=>
>> person.name)` is less verbose for the stated use case
>>
>> On Fri, 11 Aug 2017 at 11:55 Darien Valentine <valentin...@gmail.com>
>> wrote:
>>
>>> @Alexander The idea of a generalized `map` function (etc, I’m guessing)
>>> is
>>> appealing. From the way you talked about it, it sounds like there may
>>> have been
>>> past discussion on the topic. Are there any proposals for this or major
>>> ideas
>>> being batted around?
>>>
>>> > Why? What's the advantage? You lose at least the square bracket and dot
>>> > notations for access, as disadvantages, and I'm not aware of any
>>> advantages.
>>> > If there aren't any that compensate for the disadvantages, then it's a
>>> net
>>> > negative
>>>
>>> @Naveen — a handful of things. Objects are indeed a perfectly reasonable
>>> choice
>>> for modeling kvp collections a lot of the time. On the other hand,
>>> because
>>> objects in ES serve double duty as ways to model data and ways to "model
>>> code",
>>> they are not always ideal for the former case on account of the features
>>> that
>>> exist mainly to serve the second. Some examples of things that make maps
>>> useful:
>>> inherently iterable; no prototype chain access lookup; no collision with
>>> `Object.prototype` property name when hashing by arbitrary keys;
>>> potentially
>>> more efficient for situations where keys are frequently removed;
>>> `map.has()` is
>>> more straightforward than having to consider whether you want `key in` or
>>> `Object.hasOwnProperty` or which properties have been defined as
>>> enumerable or
>>> not; iteration order of entries is 1:1 with insertion order; and of
>>> course, keys
>>> can be of any type. Further, maps can be subclassed to constrain the
>>> types that
>>> they may hold or add other behaviors without needing to define custom
>>> Proxies.
>>>
>>> Some general use cases: registries; hashing data where keys are from
>>> external
>>> input; kvp collections which are ordered; kvp collections which will be
>>> subject
>>> to later transformations; kvp collections to which new keys are
>>> frequently added
>>> or removed.
>>>
>>> While I hope that information is somewhat helpful, there are probably
>>> much more
>>> detailed resources online (including, I suspect, past discussions on
>>> this list)
>>> which could explain some of those things better or which include cases I
>>> haven’t
>>> thought of.
>>> _______________________________________________
>>> 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
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
