Object self-promotes because it is nearly always a perfect fit for this: great performance, great literal syntax, concise access syntax. The only compelling case to use a map instead is when insertion ordering is required, despite the MDN article. I wouldn't oppose an equivalent `Array.prototype.toMap` and `Map.fromIterable`, I would just hardly ever use it
On Sun, 13 Aug 2017, 10:33 p.m. Alexander Jones, <a...@weej.com> wrote: > Honestly, promoting the use of Object for this, and coupling the solution > to Array, feels like the wrong direction for the language to me personally. > By definition, such a map constructed from a set of homogenous values, for > indexing purposes, has a clear key and value type. This guidance from MDN > seems to be the right message we should be sending to developers: > > > https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Map > > > ... ask yourself the following questions: > > > > * Are keys usually unknown until run time? Do you need to look them up > dynamically? > > * Do all values have the same type? Can they be used interchangeably? > > * Do you need keys that aren't strings? > > * Are key-value pairs frequently added or removed? > > * Do you have an arbitrary (easily changing) number of key-value pairs? > > * Is the collection iterated? > > > > If you answered 'yes' to any of those questions, that is a sign that you > might want to use a Map. Contrariwise, if you have a fixed number of keys, > operate on them individually, or distinguish between their usage, then you > probably want to use an Object. > > > On 13 August 2017 at 05:49, Naveen Chawla <naveen.c...@gmail.com> wrote: > >> Verbosity. >> >> It's a task common across many project types and involves only 2 >> fundamental types in ES: array and object >> >> Compare: >> >> ``` >> const cache = array.reduce((cache, element)=>{cache[element.id] = >> element; return cache;}, {}); >> ``` >> >> with >> >> ``` >> const cache = array.toObject(element=>element.id); >> ``` >> >> since the signature would offer additional optional `valueFromElement` >> and `startingObject` parameters nobody loses anything. >> >> On Sun, 13 Aug 2017 at 09:51 Barret Furton <barretfur...@gmail.com> >> wrote: >> >>> Why not embrace `Array.prototype.reduce` instead of trying to abstract >>> it away? >>> >>> ```js >>> const identity = a => a >>> >>> const toObject = (fk, fv = identity) => >>> (acc, curr) => (acc[fk(curr)] = fv(curr), acc) >>> >>> const arr = [['a', '1'], ['b', '2'], ['c', '3']] >>> >>> arr.map(a => [a[0], parseInt(a[1], 10)]) >>> .filter(a => a[0] !== 'c') >>> .reduce(toObject(a => a[0]), {}) // { a: 1, b: 2 } >>> ``` >>> >>> `reduce(toObject)` clearly communicates intent, and you can even provide >>> an existing object for merging. >>> >>> On Sat, Aug 12, 2017 at 1:58 PM, Naveen Chawla <naveen.c...@gmail.com> >>> wrote: >>> >>>> 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 >>>> >>>> >>> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
