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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> >>>> Not a rule. Just an email to this board. >>>> >>>> On Thu, May 30, 2019 at 7:26 AM Григорий Карелин <[email protected]> >>>> 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 <[email protected]>: >>>>>> >>>>>> > 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 Григорий Карелин <[email protected]> >>>>>> 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 <[email protected]>: >>>>>>>> >>>>>>>> > 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 Григорий Карелин <[email protected]> >>>>>>>> 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 _ <[email protected]>: >>>>>>>>>> >>>>>>>>>> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss -- Atenciosamente, Augusto Borges de Moura _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
