Darien Valentine (2017-08-07T15:17:59.000Z)
> Where are you thinking of? [re: other methods that could take
overloaded/shorthand map/predicate args, but do not]

These could also accept strings for property mapping in the same manner you
proposed, but do not currently:

- `Array.from`
- `Array.prototype.every`
- `Array.prototype.filter`
- `Array.prototype.map`
- `Array.prototype.some`
- `new Map`
- `new Set`

Mind, I’m not arguing that it isn’t a useful idea. Where lodash has
equivalents for the above, strings are permitted, and I’m sure people make
use of that functionality.

I think the spot where we might disagree is the assessment that "the string
case is overwhelmingly the common one." This doesn’t sound quite right to
me. That’s not been true in my experience, though I don’t have any data to
say concretely one way or another. In any case, I’m not out to block
anything if smarter people think it’s a good idea.

>  I'll create a proposal for what I want in a few days after more feedback
has come in.

Would you consider the method you’ll be proposing to be "instead of" a
reverse-of-object-entries type proposal, or is it orthogonal to that?

> You seem to have had some private reply about an upcoming proposal
template...?

Yeah — it doesn’t exist yet, however.

On Mon, Aug 7, 2017 at 9:46 AM, T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:

> 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
> template...?
>
> -- T.J. Crowder
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170807/1e3aec59/attachment.html>
valentinium at gmail.com (2017-08-07T15:19:46.450Z)
> Where are you thinking of? [re: other methods that could take overloaded/shorthand map/predicate args, but do not]

These could also accept strings for property mapping in the same manner you
proposed, but do not currently:

- `Array.from`
- `Array.prototype.every`
- `Array.prototype.filter`
- `Array.prototype.map`
- `Array.prototype.some`
- `new Map`
- `new Set`

Mind, I’m not arguing that it isn’t a useful idea. Where lodash has
equivalents for the above, strings are permitted, and I’m sure people make
use of that functionality.

I think the spot where we might disagree is the assessment that "the string
case is overwhelmingly the common one." This doesn’t sound quite right to
me. That’s not been true in my experience, though I don’t have any data to
say concretely one way or another. In any case, I’m not out to block
anything if smarter people think it’s a good idea.

>  I'll create a proposal for what I want in a few days after more feedback has come in.

Would you consider the method you’ll be proposing to be "instead of" a
reverse-of-object-entries type proposal, or is it orthogonal to that?

> You seem to have had some private reply about an upcoming proposal template...?

Yeah — it doesn’t exist yet, however.