[proposal] Object.pick

[Mikkel Davis]

@Bob
I'm sorry to hear that has been the response here thus far. I'm encouraged,
though, to hear there are others like you who see the value in this native
ability. I think those are great points about defaults and renaming. The
util approach may or may not be able to implement those effectively.
Hopefully, we'll see if I or anyone else here can recommend some viable
ideas there.

One thing I don't quite follow, though, is the point about a util being
easy to implement in user code. The same can be said of
Array.prototype.map, String.prototype.startsWith, Object.keys, or
Object.assign. The polyfills for each of those are a few lines long. Yes,
perhaps I would embrace something like `'a'^str`, as a hypothetical
example, instead of `str.startsWith('a')`. Maybe, haha. But imagine if
something like that actually makes it into the language some day. Does that
mean it was not worth it to include String.prototype.starsWith in the first
place?

---
Mikkel R. Davis


On Thu, Jul 26, 2018 at 8:30 PM Bob Myers <rtm at gol.com> wrote:

> @Mikkel,
>
> My impression is that one can summarize the attitude of people on this
> mailing list and those involved in the language design process toward
> property picking as somewhere between "I don't care enough to worry about
> it" and "it doesn't belong in the language". To put it a different way, if
> picking was ever going to get onto the spec track,it already would have.
> Personally I disagree, but that's a different matter.
>
> That is quite unlikely to change whether picking is implemented in syntax
> or as some new `Object` method. I think the latter is actually likely to
> get even less traction due to the fact that it can be implemented quite
> trivially in user code and ends up looking quite clunky. Would you really
> rather write `Object.pick(obj, ['a', 'b'])` or `obj.{a, b}`, as one
> proposal would have it? How does the `Object.pick` approach provide things
> like defaults and renaming that are useful when picking and are already in
> deconstructing syntax which is leveraged directly in the existing
> syntax-based proposals, where one can say things like `obj.{a = 2, b: c}`?
>
> Bob
>
> On Fri, Jul 27, 2018 at 3:12 AM Mikkel Davis <mikkeld at gmail.com> wrote:
>
>> Thank you, TJ. Those are some other interesting options. But undesirable,
>> like you say, least of which because they all require repetition like my
>> snippet in my original post. At least the array of properties avoids the
>> repetition. I agree it's not ideal because of the extra quote marks, but my
>> IDE is still able to follow the logic and point me to where the
>> property/method was included down the line. And really properties are just
>> strings. The quotes would be required anyway with a syntactic solution for
>> properties such as "thing-1", "2thing".
>>
>> I would love to see a great syntactic solution like the one you
>> mentioned, but as we know it is far more involved to implement those and
>> many do not survive for a variety of reasons. Why not pursue both
>> proposals? We have Array.prototype.concat and array spread, Object.assign
>> and object spread, Boolean(val) and !!val. I realize not all of those are
>> entirely equivalent--my point is that I think there is value in pursing
>> this proposal separate from syntax.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180727/25d8a915/attachment.html>