Optional assignment operator

[Jacob Pratt]

I _personally_ have not found that to be a source of problems in this
instance, though I do on occasion have side effects in setters, such as
saving into a database, emitting data on a WebSocket instance, etc. They
could be debounced, but that's not always a feasible option.

I'd be interested to hear what others have to say about this proposal, as
this is (in all honesty) just something I came across and thought there
might be a better solution. The alternative you proposed, though not
identical, would work in the majority of cases. At least to me, it wasn't
immediately clear what it does when looking at it. Of course I fully
understand it, it's just something that might need a comment to explain.

jhpratt

On Wed, Jul 4, 2018 at 8:50 PM, Darien Valentine <valentinium at gmail.com>
wrote:

> True — though I’m not sure why concern for this case would merit new
> syntax. Have you found that to be a common source of problems? Usually
> setters are light / idempotent.
>
> (Not opposed to the premise btw — just trying to hear more about what
> problems it would solve, especially since syntactic solutions usually have
> to be pretty high-value or else address something which can’t be  solved
> any other way.)
>
> On Wed, Jul 4, 2018 at 8:41 PM Jacob Pratt <jhprattdev at gmail.com> wrote:
>
>> Sure, you'd be making an assignment no matter what in that case, which
>> would unnecessarily trigger the setter, possibly causing side effects.
>>
>> ```
>> const obj = {
>>   get x() {
>>     return _x;
>>   },
>>
>>   set x(value) {
>>     console.log('setter called');
>>     _x = value;
>>   },
>>
>>   demo(params = {}) {
>>     ({ x: this.x = this.x } = params);
>>   },
>> };
>>
>> obj.demo({ x: 5 });
>> obj.demo({ x: undefined });
>> ```
>>
>> This will log twice, where it only needs to trigger it once.
>>
>> jhpratt
>>
>> On Wed, Jul 4, 2018 at 8:16 PM, Darien Valentine <valentinium at gmail.com>
>> wrote:
>>
>>> > My thought was to have the following: this.foo ?= params?.foo; which
>>> can be desugared to if (($ref = params?.foo) !== undefined) { this.foo =
>>> $ref; }
>>>
>>> Are there any specific advantages to the new syntax you’re describing?
>>> Initially, it appears to me like a less powerful form of an existing
>>> syntactic feature — default initializers and binding patterns allow
>>> expressing the same logic:
>>>
>>> ```
>>> const obj = {
>>>   demo(params={}) {
>>>     ({ foo: this.foo=this.foo } = params);
>>>
>>>     console.log(
>>>       `params was ${ JSON.stringify(params) }; ` +
>>>       `this.foo is now ${ JSON.stringify(this.foo) }`
>>>     );
>>>   }
>>> }
>>>
>>> obj.demo({ foo: 1 });
>>> obj.demo({})
>>> obj.demo({ foo: 2 });
>>> obj.demo();
>>> obj.demo({ foo: 3 });
>>> obj.demo({});
>>> ```
>>>
>>> _______________________________________________
>>> 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/20180704/5503a0b0/attachment-0001.html>