Proposal: syntactic sugar for extracting fields from objects

Cyril Auburtin cyril.auburtin at gmail.com
Fri May 31 09:07:35 UTC 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190531/be6ee95e/attachment-0001.html>


More information about the es-discuss mailing list