Destructuring by &reference

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Mar 3 16:24:46 UTC 2021


The way I see it: it's just a convention/shortcut to have the destructured
object around.

```js
function augment({&value}, testCase) {
  if (/thing/.test(testCase))
    value += testCase;
}

let any = {value: ''};
augment(any, 'thing');
```

The magical behavior goal is to define side effects when overwriting
properties ... for instance:

  * a destructured property, as getter, is just a value
  * every destructured property can be overwritten ... as these are just
references

Now here some wonder:

```js
let any = {
  get value() { return 'no setter'; },
  method() {
    console.log(this.value);
  }
};

function stuff({&value, &method}, extra) {
  method(); // "no setter"

  // throws an error
  value = extra;
}
```

Basically, at the engine level, is just a shortcut for having the original
destructure object around, so that both `&value` and `&method` would behave
exactly like `object.value = ...` or `object.method();`

I personally don't know how many times I wanted this simplicity, as
opposite of going through this pattern:

```js
function stuff(source, extra) {
  const {value, method} = source;

  if (condition)
    method.call(source);

  if (value === extra)
    source.value = 'no more';
}
```

The constant change between having the value once, then eventually needing
to remember the source is missing, so the function needs refactoring, or it
needs binding, or it needs ... you name it, I think referencing the source
object somehow, would allow a lot of refactoring, smaller code, and easier
to reason about, in IDEs (special highlights for referenced variables), in
developers intent (no need to grab the source repeatedly when updates are
needed), and in clarity (having an explicit & in destructuring describes
the intent of wanting to deal with that value as reference).

My only concern here would be: what if we pass that value to another
signature? Well, as long as we don't also have a way to pass such value as
reference, in example, "restructuring", as in `callback({&value, other})`
instead of just `callback({value, other})`, this should be a no-brainer,
but maybe the two ideas should be spec'd together, and also ship together,
so that you can propagate a single "*reaction point*" down the lane,
without leaking the whole object across the whole lane.

I hope this makes sense, but that's the idea behind. The fact C can point
at pointers and force-update this but JS needs whole objects propagations
everywhere, in a highly reactive situation, like the one we have these
days, bugs me way too much.

Regards 👋


On Wed, Mar 3, 2021 at 4:47 PM Augusto Moura <augusto.borgesm at gmail.com>
wrote:

> I don't know, the by reference destructuring seems a bit too much magical,
> a scoped variable that sets to a property to a object just sounds like the
> old `with` statement but reduced and more explicit, given is just a sugar
> and currently the problem is not a great of a pain point I would be very
> picky a proposal like that, any prior art in other languages?
>
> Also, from a grammar/vendor implementation standpoint I would imagine the
> definition of a by reference variable bind would be kinda fishy, I might be
> wrong though
>
> Em ter., 2 de mar. de 2021 às 21:03, Claudia Meadows <
> contact at isiahmeadows.com> escreveu:
>
>> I would like to see this happen, though I'd like to see it integrated
>> with reified refs. (I know there's a proposal laying around somewhere
>> drafted up by a current or former TC39 person, but I can't find it.)
>>
>> -----
>>
>> Claudia Meadows
>> contact at isiahmeadows.com
>>
>>
>> On Tue, Mar 2, 2021 at 11:05 AM Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> Another one (cit. DJ Khaled)
>>>
>>> has "by reference" ever been considered as "yet another JS syntax" ???
>>>
>>> let object = {value: 1};
>>> let {&value} = object;
>>> value = 2;
>>>
>>> object.value; // 2
>>>
>>> allowed everywhere destructuring is possible, throwing for frozen
>>> properties ... is this just meh? .. .'cause I think, specially for function
>>> signatures declaration, it might make a difference, when mutability matters.
>>>
>>> Cheers 👋
>>>
>>> P.S. for transpilers this would simply carry, repeatedly, the initial
>>> reference.prop around, instead of using just prop.
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20210303/8c96f551/attachment.html>


More information about the es-discuss mailing list