guest271314 at gmail.com (2019-05-31T16:10:35.320Z)
```
let obj = {a:1};
let pickedObj = {};
({a:pickedObj.a} = obj);
```
is already currently possible.
```const pickedObj = {...obj: {a, b, c}}``` would be less code.
If ```c``` is not a property of ```obj``` would the expected result at ```pickedObj``` be ```{a:1, b:2, c:undefined}``` or ```{a:1, b:2}``` with ```c``` omitted?
guest271314 at gmail.com (2019-05-31T16:08:21.928Z)
Where is ```obj``` defined at ```const pickedObj = {...obj: {a, b, c}}```? Currently ```{...obj: {a, b, c}}``` syntax is not possible, though
```
let obj = {a:1};
let pickedObj = {};
({a:pickedObj.a} = obj);
```
is already currently possible.
```const pickedObj = {...obj: {a, b, c}}``` would be less code.
guest271314 at gmail.com (2019-05-31T16:07:08.388Z)
Where is ```obj``` defined at ```const pickedObj = {...obj: {a, b, c}}```? Currently ```{...obj: {a, b, c}}``` syntax is not possible, though
```
let obj = {a:1};
let pickedObj = {};
({a:pickedObj.a} = obj);
```
is already currently possible.
guest271314 at gmail.com (2019-05-31T16:04:40.524Z)
Where is ```obj``` defined at ```const pickedObj = {...obj: {a, b, c}}```? Currently ```{...obj: {a, b, c}}``` syntax is not possible, though
```
let obj = {a:1};
let pickedObj = {};
({a:pickedObj.a} = obj);
```
is currently possible.
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>