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 <[email protected]>
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 <
> [email protected]> 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
>> [email protected]
>>
>>
>> On Tue, Mar 2, 2021 at 11:05 AM Andrea Giammarchi <
>> [email protected]> 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
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
