Doesn't that bring risks to breaking the web? You seen, many, MANY servers running php have the "shot-tags" feature enabled, in which pages with <? and ?> will be interpreted. In this case, any html page with embedded scripts using this operator, or event .js files when the server is configured to also run php in them, will break.
Or am I missing something here? [ ]s *--* *Felipe N. Moura* Web Developer, Google Developer Expert <https://developers.google.com/experts/people/felipe-moura>, Founder of BrazilJS <https://braziljs.org/> and Nasc <http://nasc.io/>. Website: http://felipenmoura.com / http://nasc.io/ Twitter: @felipenmoura <http://twitter.com/felipenmoura> Facebook: http://fb.com/felipenmoura LinkedIn: http://goo.gl/qGmq --------------------------------- *Changing the world* is the least I expect from myself! On Fri, Sep 6, 2019 at 4:59 AM 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
