Proposal: syntactic sugar for extracting fields from objects

guest271314 guest271314 at gmail.com
Fri May 31 15:57:24 UTC 2019


Where is ```obj``` defined at ```const pickedObj = {...obj: {a, b, c}}```?

On Fri, May 31, 2019 at 9:08 AM Cyril Auburtin <cyril.auburtin at gmail.com>
wrote:

> After thinking about it, the dot-notation is maybe confusing, because
>
> ```js
> obj.{a}
> ```
> looks like
> ```js
> obj.a
> ```
> But the results are totally different
>
> Maybe a different syntax might be clearer
> ```js
> obj{a, b, c}
> // or
> const pickedObj = {...obj{a, b, c}}
> // or
> const pickedObj = {...obj: {a, b, c}}
> ```
>
> On Fri, May 31, 2019 at 1:43 AM Bob Myers <rtm at gol.com> wrote:
>
>> >  Another argument is
>> that a `pick` helper function is really easy to be implemented and the
>> problem that the syntax resolves is mostly aesthetic
>>
>> We've been over this ground before.
>>
>> Yes, there's a valid cost/benefit question for any syntactic sugar
>> proposal, and no one would claim there is not one here as well.
>>
>> However, we write `o.p` and `{p: v}`, where `p` is not required to be
>> quoted, so being forced to quote each and every property name as the
>> argument to a pick API is not very attractive. In addition, pick APIs such
>> as lodash do not provide any of the machinery already designed and
>> introduced for destructuring to allow renaming and defaults, which the
>> extended dot notation gives us "for free", since the thing in curly
>> brackets on the right-hand side is precisely a deconstructing construct, as
>> in
>>
>> ```
>> obj.{a = 2, b: c, d: {e}}}
>> ```
>>
>> which defaults `obj.a` to the value 2, renames `b` to `c` on the way out,
>> and plucks `e` from inside `d`; this kind of thing is hardly feasible in an
>> API. This is not new syntax. We already have the syntax. The single new
>> thing is allowing it on the right side of dots. That's it. It does not
>> increase messiness, it reduces it.
>>
>> Bob
>>
>>
>>
>>
>> On Thu, May 30, 2019 at 3:49 PM Augusto Moura <augusto.borgesm at gmail.com>
>> wrote:
>>
>>> Just bringing to the table the other side of the discussion (not
>>> agreeing with all of them)...
>>> IIRC the biggest problem with a pick syntax is the syntactic noise
>>> encouraging convoluted code. Even now just with destructuring and
>>> arrow functions code can get messy really quickly. Another argument is
>>> that a `pick` helper function is really easy to be implemented and the
>>> problem that the syntax resolves is mostly aesthetic (even that is
>>> questionable given the first argument, terseness != legibility).
>>>
>>> IMHO just a `pick` function in the standard library would suffice most
>>> of the problems that the syntax is trying to solve. Maybe something
>>> like `Object.pick` or `Object.pickKeys` or
>>> `Object.smooshIntoObjectTheValuesOf`
>>>
>>> Em qui, 30 de mai de 2019 às 15:43, Bob Myers <rtm at gol.com> escreveu:
>>> >
>>> > It would be fabulous if we could get one or more of these proposals
>>> implemented as a Babel feature, but I think this would require the Babel
>>> team making the relevant changes to Babylon, and my understanding is that
>>> they do this only for features that have at least already started down the
>>> committee track--understandable, but a kind of catch-22.
>>> >
>>> > You are one of many people whoi have wondered about this kind of
>>> feature over the years, including dozens of Stack Overflow members, calling
>>> it by different names, including picking, extended destructuring, extended
>>> dot notation, picked properties, etc. My own proposal at
>>> https://github.com/rtm/js-pick-notation is just one of several,
>>> although I should mention that it represents the outcome of multiple
>>> iterations of research and thinking, and its documentation is IMHO
>>> relatively clean and complete, although it does not include the actual
>>> proposed changes to the ECMAScript spec which need to be created at some
>>> point.
>>> >
>>> > Bob
>>> >
>>> > On Thu, May 30, 2019 at 11:29 AM Jacob Pratt <jhprattdev at gmail.com>
>>> wrote:
>>> >>
>>> >> My understanding is that Babel does support proposals, even if they
>>> require new syntax. Of course, it would require changes to the parser
>>> that's beyond my understanding of the codebase. I'd certainly help out in
>>> whatever ways I'm able to.
>>> >>
>>> >> For the record, though, I actually had this idea completely separate
>>> from the proposal — I ran across it when searching to see if anyone else
>>> had proposed such a syntax/language feature.
>>> >>
>>> >> On Thu, May 30, 2019, 14:24 Bob Myers <rtm at gol.com> wrote:
>>> >>>
>>> >>> I don't know what "community" means, other than a bunch of people
>>> subscribing to this ML, and I can't imagine how one would define, or
>>> achieve, or identify, a "consensus" of that community, or why or how the
>>> community would vote on anything, or what such the results of such a vote
>>> would mean.
>>> >>>
>>> >>> The very next step is to identify a champion. Such a champion would
>>> presumably help to shape, review, and choose between alternatives for the
>>> proposals. However, given the failure of my half-hearted efforts to find a
>>> champion, and the fact that no one has emerged as champion over the several
>>> years since these discussions started, allow me to be pessimistic.
>>> >>>
>>> >>> It's odd to me because features such as property spread/rest
>>> notation, and before that destructuring, have clearly demonstrated the
>>> appetite of the "community" for language changes to better support
>>> manipulation of properties--not surprising, since objects and their
>>> properties can be considered the fundamental data structures of the
>>> language. This specific proposal has a relatively small syntactic footprint
>>> in my opinion, and measures up well against the majority of criteria that
>>> people commonly apply to language design decisions and have been documented
>>> on this list. I can only conclude that wiser minds than my own have
>>> concluded that this particular feature simply does not rise to the level of
>>> priority of other features that are progressing down the pipeline.
>>> >>>
>>> >>> WIth regard to the notion of implementing this feature on a test
>>> basis, the most obvious approach to doing that is as a Babel plug-in, but
>>> based on my research--please-correct me if I'm wrong--Babel supports many
>>> kind of transformations but not entirely new syntax as is the case here;
>>> that requires essentialy rewriting internal parts of its parser. I have
>>> experimented with a Sweet implementation with some success, but actually
>>> I'm not really sure what that is supposed to demonstrate or if anyone would
>>> care.
>>> >>>
>>> >>> Bob
>>> >>>
>>> >>> On Thu, May 30, 2019 at 12:29 AM guest271314 <guest271314 at gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> Not a rule. Just an email to this board.
>>> >>>>
>>> >>>> On Thu, May 30, 2019 at 7:26 AM Григорий Карелин <
>>> grundiss at gmail.com> wrote:
>>> >>>>>
>>> >>>>> I'm new to this community, so I'd appreciate if you clarify: is
>>> that your opinion or is it kind of rule written somewhere?
>>> >>>>>
>>> >>>>> чт, 30 мая 2019 г. в 09:59, guest271314 <guest271314 at gmail.com>:
>>> >>>>>>
>>> >>>>>> > Wouldn't it be better to consolidate the decision? I mean as OP
>>> I vote for `from`, but if majority will say they better like `x.{y, z}`
>>> I'll take it.
>>> >>>>>>
>>> >>>>>> No. There should not be any prohibition as to the additions
>>> different solutions to a single proposal. Neither proposal is "better"
>>> right now as neither have been coded, tested, and if necessary, specified.
>>> A simple majority does not mean correct or complete. The more approaches
>>> available the more ability to compose the code from different perspectives,
>>> outputting the same result; expanding the language both in syntax and reach
>>> as to possible composition, without setting an arbitrary specification to a
>>> single majority at only this point in time.
>>> >>>>>>
>>> >>>>>> The tersest have been able to achieve so far on a single line
>>> using an immediately invoked arrow function and object rest which requires
>>> writing the identifier twice.
>>> >>>>>>
>>> >>>>>> If part of the requirement for the proposal is terse code,
>>> following the pattern of an immediately invoked arrow function if  ```=```
>>> operator between expressions ```()``` the arrow `>` and return value could
>>> be omitted as being designated implicit immediately invoked arrow function
>>> with default return value set from the destructured parameters, or
>>> ```undefined``` set as value of target identifiers, or plain object
>>> ```{}```, resulting in the syntax, within at least an object literal,
>>> possibly preceded by spread syntax, will result in
>>> >>>>>>
>>> >>>>>> ```let obj = {otherData:'other
>>> data',...(({firstName,lastName})=(user.profile)}```
>>> >>>>>>
>>> >>>>>> being equivalent to
>>> >>>>>>
>>> >>>>>> ```let obj = {otherData:'other
>>> data',...(({firstName,lastName})=>({firstName,lastName}))(user.profile)}```
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Thu, May 30, 2019 at 6:38 AM Григорий Карелин <
>>> grundiss at gmail.com> wrote:
>>> >>>>>>>
>>> >>>>>>> Wouldn't it be better to consolidate the decision? I mean as OP
>>> I vote for `from`, but if majority will say they better like `x.{y, z}`
>>> I'll take it.
>>> >>>>>>>
>>> >>>>>>> чт, 30 мая 2019 г. в 06:35, guest271314 <guest271314 at gmail.com>:
>>> >>>>>>>>
>>> >>>>>>>> > I think it's possible to find someone who will represent the
>>> will of community.
>>> >>>>>>>>
>>> >>>>>>>> Individuals can compose the code right now.
>>> >>>>>>>>
>>> >>>>>>>> > At the moment the question is does community have will to add
>>> proposed sugar to the language, and if so, which version.
>>> >>>>>>>>
>>> >>>>>>>> Why would there be any restriction on the versions of syntax
>>> which would achieve the requirement? The original proposal using ```from```
>>> and other proposals could each be created, tested, specified.
>>> >>>>>>>>
>>> >>>>>>>> On Wed, May 29, 2019 at 7:37 PM Григорий Карелин <
>>> grundiss at gmail.com> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>> True
>>> >>>>>>>>>
>>> >>>>>>>>> I think it's possible to find someone who will represent the
>>> will of community.
>>> >>>>>>>>>
>>> >>>>>>>>> At the moment the question is does community have will to add
>>> proposed sugar to the language, and if so, which version.
>>> >>>>>>>>>
>>> >>>>>>>>> ср, 29 мая 2019 г. в 22:30, Oriol _ <
>>> oriol-bugzilla at hotmail.com>:
>>> >>>>>>>>>>
>>> >>>>>>>>>> If you want to add this you will need a champion, see
>>> https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#new-feature-proposals
>>> >>>>>>>>>>
>>> >>>>>>>>>> -- Oriol
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> El 29/5/19 a les 21:15, Григорий Карелин ha escrit:
>>> >>>>>>>>>>
>>> >>>>>>>>>> I agree.
>>> >>>>>>>>>>
>>> >>>>>>>>>> So, what does community think? Do we want to have
>>> “destructuring picking” sugar in JS and if we do, which syntax looks more
>>> attractive?
>>> >>>>>>>>>>
>>> >>>>>>>>>> I’d suggest to vote
>>> >>>
>>> >>> _______________________________________________
>>> >>> es-discuss mailing list
>>> >>> es-discuss at mozilla.org
>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>> --
>>> Atenciosamente,
>>>
>>> Augusto Borges de Moura
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190531/d6e4ac77/attachment-0001.html>


More information about the es-discuss mailing list