Proposal: Named de-structuring arguments.
# Jordan Harband (6 years ago)
See zkat/proposal
See https://github.com/zkat/proposal-as-patterns On Wed, Jan 16, 2019 at 12:24 AM Sultan <thysultan at gmail.com> wrote: > The ability to both name and de-structure an argument. > > Relying on the spread operator does not archive the same effect > considering that the spread operator "by design" has some short-comings > related to exotic objects when the objects in question have a rich > prototype you want to preserve. > > Consider the following proposal: > > function fn (arg pick {a, b = arg.b = 'value'}) {} > > This would allow four fundamental things of note missing from current > de-structuring status-quo: > > 1. The ability to have both named arguments and de-structuring. > > 2. The ability to reference the named argument within the de-structure. > This allows the above pattern of setting a default value on the passed > argument when it doesn't exist. > > 3. This in turn also affords you the ability to de-structure while also > preserving the exotic nature of an object when it is not a POJO object. > > That is when "arg" is an exotic use-defined object using the spread > operator "{...arg}" will discard its prototype. > > For example: > > function a ({a, ...b}) { return b } > > a([1, 2]) > > Returns a object with index-able keys instead of the array. > > 4. Consequently this addition would also afford the avoidance of any > overhead that one might want to avoid with the rest spread operation: {a, > b, ...arg} in hot paths. > _______________________________________________ > 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/20190116/a9a79c86/attachment.html>
# Mark (6 years ago)
oof. I appreciate how terse it is, but the readability of it all is a bit scary when you're doing multiple assignments more than one level deep.
oof. I appreciate how terse it is, but the readability of it all is a bit scary when you're doing multiple assignments more than one level deep. -m On Wed, Jan 16, 2019 at 3:28 AM Jordan Harband <ljharb at gmail.com> wrote: > See https://github.com/zkat/proposal-as-patterns > > On Wed, Jan 16, 2019 at 12:24 AM Sultan <thysultan at gmail.com> wrote: > >> The ability to both name and de-structure an argument. >> >> Relying on the spread operator does not archive the same effect >> considering that the spread operator "by design" has some short-comings >> related to exotic objects when the objects in question have a rich >> prototype you want to preserve. >> >> Consider the following proposal: >> >> function fn (arg pick {a, b = arg.b = 'value'}) {} >> >> This would allow four fundamental things of note missing from current >> de-structuring status-quo: >> >> 1. The ability to have both named arguments and de-structuring. >> >> 2. The ability to reference the named argument within the de-structure. >> This allows the above pattern of setting a default value on the passed >> argument when it doesn't exist. >> >> 3. This in turn also affords you the ability to de-structure while also >> preserving the exotic nature of an object when it is not a POJO object. >> >> That is when "arg" is an exotic use-defined object using the spread >> operator "{...arg}" will discard its prototype. >> >> For example: >> >> function a ({a, ...b}) { return b } >> >> a([1, 2]) >> >> Returns a object with index-able keys instead of the array. >> >> 4. Consequently this addition would also afford the avoidance of any >> overhead that one might want to avoid with the rest spread operation: {a, >> b, ...arg} in hot paths. >> _______________________________________________ >> 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/20190116/a5268b60/attachment-0001.html>
The ability to both name and de-structure an argument.
Relying on the spread operator does not archive the same effect considering that the spread operator "by design" has some short-comings related to exotic objects when the objects in question have a rich prototype you want to preserve.
Consider the following proposal:
function fn (arg pick {a, b = arg.b = 'value'}) {}
This would allow four fundamental things of note missing from current de-structuring status-quo:
The ability to have both named arguments and de-structuring.
The ability to reference the named argument within the de-structure. This allows the above pattern of setting a default value on the passed argument when it doesn't exist.
This in turn also affords you the ability to de-structure while also preserving the exotic nature of an object when it is not a POJO object.
That is when "arg" is an exotic use-defined object using the spread operator "{...arg}" will discard its prototype.
For example:
function a ({a, ...b}) { return b }
a([1, 2])
Returns a object with index-able keys instead of the array.