You keep diverging from the intent, basing your answers on my quick'n'dirty examples. I agree my examples are probably not the best looking, but there are no solutions right now to retrieve one part of th echain that failed, if not repeating the chain, and eventually thesame errors, on the right hand side.
This is what `<?` would like to solve, and I've created a mice.trap [1] module so that maybe devs can start playing with the idea, and come back with a better experience/understanding of such idea. The point about PHP is also somehow valid, but I wasn't aware about the fact we have other PL constrains with JS syntax. [1] https://github.com/WebReflection/mice.trap#readme On Fri, Sep 6, 2019 at 2:48 PM Naveen Chawla <[email protected]> wrote: > > 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 < > [email protected]> 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 <[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
