Array.prototype.toObjectByProperty( element=>element.property )
tj.crowder at farsightsoftware.com
Mon Aug 7 13:46:59 UTC 2017
On Mon, Aug 7, 2017 at 2:23 PM, Darien Valentine
<valentinium at gmail.com> wrote:
> > For me, no; an unnecessary additional transform and too much.
> > memory churn.
> However I suspect the idea of accepting a string or symbol key
> rather than a function is unlikely to gain traction — for one,
> there’s nothing like it presently in the many places there
> _could_ be
Where are you thinking of?
> ...and perhaps more importantly, that overloading represents an
> additional cost for every use case, even if it might reduce the
> cost for one.
That's a fair concern, although the test is trivially simple and very fast.
I'll flag up again the precedent of `String#replace`. In my experience, the
string use case is overwhelmingly the common one. So slowing down the
common case because of edge cases outweighs that concern for me. In spec
terms, I'd test first for string, then function, then Symbol. (In polyfill
terms, it'd be a `switch` on `typeof`.)
> Assuming that proposal isn’t a flop, please feel free to open an
> issue on the repo making the case for the map argument...
I don't think your `Object.fromEntries` isn't similar enough to what I
want. I'll create a proposal for what I want in a few days after more
feedback has come in.
You seem to have had some private reply about an upcoming proposal
-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss