guest271314 at gmail.com (2019-05-30T07:27:34.471Z)
> 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.
Given in principle either proposal and approach would presumably output the same result, is the vote on the least code to output the result or user preference by way of vote? If there is a vote for which single proposal relevant to destructuring assignment, why should the criteria not be objectively the least code written to output same result once implemented - without user preference being involved at all? If ```x.{y, z}``` or ```...x.{y, z}``` is least bytes then specify ```x.{y, z}``` based on least bytes alone.
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
```let obj = {otherData:'other data',...(({firstName,lastName})=>({firstName,lastName}))(user.profile)}```
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))}```
or
```let obj = {otherData:'other data',...{firstName,lastName}(user.profile)}```
being equivalent to the object rest followed by immediately invoked arrow function.
guest271314 at gmail.com (2019-05-30T07:24:58.844Z)
> 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.
Given in principle either proposal and approach would presumably output the same result, is the vote on the least code to output the result or user preference by way of vote? If there is a vote for which single proposal relevant to destructuring assignment, why should the criteria not be objectively the least code written to output same result once implemented - without user preference being involved at all? If ```x.{y, z}``` or ```...x.{y, z}``` is least bytes then specify ```x.{y, z}``` based on least bytes alone.
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))}```
or
```let obj = {otherData:'other data',...{firstName,lastName}(user.profile)}```
being equivalent to
```let obj = {otherData:'other data',...(({firstName,lastName})=>({firstName,lastName}))(user.profile)}```guest271314 at gmail.com (2019-05-30T07:05:42.333Z)
> 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.
Given in principle either proposal and approach would presumably output the same result, is the vote on the least code to output the result or user preference by way of vote? If there is a vote for which single proposal relevant to destructuring assignment, why should the criteria not be objectively the least code written to output same result once implemented - without user preference being involved at all?
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)}```guest271314 at gmail.com (2019-05-30T07:04:33.693Z)
> 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.
Given in principle either proposal and approach would presumably output the same result, is the vote on the least code to output the result or user preference by way of vote? If there is a vote for which single proposal relevant to destructuring assignment, why should the criteria not be objectively the least code written to output same result once implemented - without user preference being involved at all?
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)}```guest271314 at gmail.com (2019-05-30T07:03:47.190Z)
> 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.
Given in principle either proposal and approach would presumably output the same result, is the vote on the least code to output the result or user preference by way of vote? If there is a vote for which single proposal relevant to destructuring assignment, why should the criteria not be objectively the least code written to output same result once implemented - without user preference being involved at all?
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)}```
> 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 listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> > > -- > С уважением, > Карелин Григорий > _______________________________________________ > 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/20190530/d0c13cab/attachment-0001.html>