rtm at gol.com (2019-05-31T05:49:14.780Z)
> 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
> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190530/8bf3ad7f/attachment-0001.html>