Proposal: named and bound deconstructions

Isiah Meadows isiahmeadows at gmail.com
Thu Jan 25 04:32:46 UTC 2018


I'm just not convinced it adds anything substantial. Destructuring
made it possible to flatten 3-5 lines to 1, along with the ability to
provide defaults. This just:

1. Lets you give a name to a temporary object, when an extra statement
does this for you. (It's rare to want to alias more than one thing.)
2. Let's you auto-bind a property when extracting it. (This could be
suggested in an issue in the [bind operator's repo][1], and is more
relevant there.)

Also, with recent talks about [making operator-bound callbacks
idempotent in the bind operator proposal][2], that could reduce bound
methods to just a simple property-like "access".

[1]: https://github.com/tc39/proposal-bind-operator.
[2]: https://github.com/tc39/proposal-bind-operator/issues/46#issuecomment-359248949
-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


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


More information about the es-discuss mailing list