The purpose is to address what chaining lacks, in terms of "stopping" at
some point whenever it's available or not.
Take this example:
```js
// the current chaining operator
const result = nmsp.some.payload()?.result ?? nmsp.some.payload();
// the mouse operator
const result = nmsp.some.payload()<?.result;
```
Keeping it semantic, the mouse operator is "a trap" for the chain that
makes reading possible expensive parts of the chain easier. An utility to
obtain the same code would look something like the following:
```js
// the mouse utility
const mouse = trap => {
// a way to self clean right after, as it is for RegExp.$* values
// which is something impossible to obtain with regular syntax
Promise.resolve(mouse.trap = trap).then(() => delete mouse.trap);
return trap;
};
// the previous example
const result = mouse(nmsp.some.payload())?.result ?? mouse.trap;
```
Since there is no easy way to syntactically obtain the same with the
current `?` and `??` without repeating all steps in the right side of the
`??`, I've thought this "mouse operator" would play a role to actually
avoid bugs easily introduced by repeating calls on the right hand side of
the `??` either via getters or expensive operations.
It is also possible to keep going on a chain or eventually provide
feedbacks of what went wrong:
```js
const name = await some.query(id)<?.rows?.[0]?.name;
if (typeof name !== 'string')
throw name;
```
As summary, considering how semantic it's the operator in both visual and
practical meanings, and considering it's not possible to achieve the same
result through `??`, I wish it would be considered as complementary help
for the recently introduced `?.` and `??` syntax.
So thanks in advance for possible consideration.
Regards
On Fri, Sep 6, 2019 at 9:14 AM Naveen Chawla <[email protected]> wrote:
> I think introducing this operator encourages bad logic design like
> "instanceof", isArray etc. These are unreadable disambiguation factors in
> that they don't inform about which part the expression is going to the next
> stage in the process. Also it leads to "type branching", which tends
> towards more convoluted logical flow. These things, in my mind, would lead
> to more bugs. Hence I would tend to be against introducing it, especially
> in light of other proposals that I find more useful that haven't been taken
> even to discussion.
>
> On Fri, 6 Sep 2019, 07:58 Claude Pache, <[email protected]> wrote:
>
>>
>>
>> Le 5 sept. 2019 à 23:39, Andrea Giammarchi <[email protected]>
>> a écrit :
>>
>> This is basically a solution to a common problem we have these days,
>> where modules published in the wild might have a `default` property, to
>> support ESM logic, or not.
>>
>> ```js
>> // current optional chaining logic
>> const imported = exported?.default ?? exported;
>>
>> // my "mice operator" proposal
>> const imported = exported<?.default;
>> ```
>>
>>
>>
>> The semantics of the `?.` in `exported?.default` is not to check whether
>> the `default` property exists, but whether `exported` evaluates to
>> undefined or null. If the `default` property is absent, `exported.default`
>> has always evaluated to `undefined`, and there is no need to optional
>> chaining operator. So that I guess you actually meant:
>>
>> ``js
>> const imported = exported.default ?? exported;
>> ```
>>
>>
>> —Claude
>> _______________________________________________
>> 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
