I'm not in TC39, sorry if I sounded like I was, just voicing my opinion.
I think the example you gave is better served by throwing the exception
from inside "query", instead of doing a "typeof" with the proposed operator
afterward.
I find "type branching" normally to be a cumbersome logical flow.
Ordinarily the branching can be factored into a common "method" between the
types, so that logical flow doesn't need the branching at all (the method
"override" does it for you), but in the case of a "mouse" operator, you
could often be dealing with completely different types, for which a "common
method" may not make sense in the logical flow, thereby necessitating the
"type branching" featured in all your examples so far.
To me "type branching" is a non-communicative style of programming. The
reader may not know the exact "type" of a particular property or
method/function's return value, even more so in JavaScript. Even worse if
the method may return different types depending on conditions. It is this
lack of clarity that I think can introduce bugs. The remedy, in my mind, is
a consistent (non-branching) logical flow. I think that language constructs
should encourage that type of programming and discourage type branching
(and other patterns that risk having a lack of logical clarity).
Just my opinion, as I said. Disagreements welcome.
On Fri, 6 Sep 2019 at 08:59, Andrea Giammarchi <andrea.giammar...@gmail.com>
wrote:
> 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 <naveen.c...@gmail.com>
> 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, <claude.pa...@gmail.com> wrote:
>>
>>>
>>>
>>> Le 5 sept. 2019 à 23:39, Andrea Giammarchi <andrea.giammar...@gmail.com>
>>> 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
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
