Proposal: Named de-structuring arguments.
# Jordan Harband (7 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 (7 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.
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190116/166e35b4/attachment.html>