<div dir="ltr">Well, deconstruction is already mostly just syntactic sugar to accomplish related things in a single, concise, declarative step; this seems like a natural extension of that philosophy.<br><br>Why add extra steps like below when you don't have to? I want JS to be as expressive as possible.<br>```<div>const { foo, bar, baz } = obj;<br>[ foo, bar, baz ].forEach(fn => fn.bind(obj);<br>// VS</div><div>const { ::foo, ::bar, ::baz } = obj;<br>```</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 24 Jan 2018 at 13:59 Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What can this do that a second variable declaration can't, apart from<br>
the auto-binding syntax (which already feels a little more like a<br>
tack-on feature rather than something that fits)? And beyond a "that's<br>
nice" kind of thing, how would this bring substantial benefit to the<br>
programmer?<br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:me@isiahmeadows.com" target="_blank">me@isiahmeadows.com</a><br>
<br>
Looking for web consulting? Or a new website?<br>
Send me an email and we can get started.<br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
<br>
On Wed, Jan 24, 2018 at 7:35 AM, Michael Rosefield<br>
<<a href="mailto:rosyatrandom@gmail.com" target="_blank">rosyatrandom@gmail.com</a>> wrote:<br>
> Deconstructions are great, but have some pain points I'd like to address.<br>
><br>
> Named deconstructions<br>
><br>
> When deconstructing elements of an object/array, you lose any reference to<br>
> the object itself. That reference is useful, not only in the trivial way of<br>
> being able to simply use it as per normal, but to clarify intent.<br>
><br>
> ```<br>
> const someMiddlewareFn = (original, updated, next) => {<br>
>   const [ { name }, { name: newName } ] = [ original, updated ]; // any<br>
> useful deconstructions<br>
>   if (name !== newName) { // do stuff }<br>
>   return next(original, updated);<br>
> }<br>
> ```<br>
> In that example we can't deconstruct `original` or `updated` in the<br>
> parameter definition, because we have to keep references to them to pass to<br>
> `next`; we have to do it in the function body, instead.<br>
><br>
> By keeping the named parameters, though, we glean more information as to the<br>
> intent of the function: `original` and `updated` directly imply that we're<br>
> comparing state changes.<br>
><br>
> There might also be occasions when we want to do something like this:<br>
><br>
> ```<br>
> const { bar } = foo,<br>
>       { baz, blah } = bar;<br>
> ```<br>
><br>
> Here, we might find it useful to get deconstructed references to both `bar`<br>
> and its properties `baz` and `blah`, but we have to do it in two steps.<br>
><br>
> I propose that we use a symbol to signify that we wish to keep a reference,<br>
> in passing. We should also allow for renaming, which is made slightly<br>
> awkward because the current renaming syntax prevents further deconstruction.<br>
><br>
> Suggestion (using !-prefix)<br>
><br>
> ```<br>
> const { !bar: { baz, blah } } = foo, // no renaming<br>
>       { bar: !myBar : { baz, blah } } = foo, // renaming<br>
><br>
>      someMiddlewareFn = (!original: { name }, !updated: { name: newName },<br>
> next) => {<br>
>         if (name !== newName) { // do stuff }<br>
>         return next(original, updated);<br>
><br>
> ```<br>
> I think that this should be clear to interpret for both coders and JS<br>
> engines.<br>
><br>
> Bound deconstructions<br>
><br>
> Some methods rely on their context being bound to their containers, and<br>
> require extra binding faff if you want to extract them; this is the<br>
> pain-point area that the binding operator proposal<br>
> <a href="https://github.com/tc39/proposal-bind-operator" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-bind-operator</a> is intended to address.<br>
><br>
> My 2nd suggestion is that we co-opt its `::` syntax for use in<br>
> deconstructions:<br>
><br>
> ```<br>
> const { ::foo } = bar;<br>
> // equivalent to<br>
> // const foo = bar.foo.bind(bar)<br>
> ```<br>
><br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
><br>
</blockquote></div>