Yes, we can all use N variables in the middle of a chain, but
`any.thing().that.queries().rows` is a more common/natural pattern.
Like in everything in JS, developers need to know what they are doing.
Every operator can create bugs (i.e. NaN results or bad string
concatenations instead of sums)
I wasn't comparing it to your `??` variant of the same cases, which has the
same issues - but only because that is a curious way of using `??` in the
first place. Ordinarily `??` would be used to resolve to a value *of the
same type* to allow clear unambiguous data flow through the variables.
I guess we have a different opinion about what's confusing and what's not.
To me having a `??` with potential side-effects is more bug prone than the
proposed mouse trap, as it's subtle, yet "promoted" by the `?.` + `??`
pattern.
On Mon, Sep 9, 2019 at 11:16 AM Naveen Chawla wrote:
>
"resultsContainerOrSingleResult" appears to be the end variable. I just
find this "shoehorning" to be a sacrifice in code clarity and
manageability. "rowCount" would be undefined if greater than 0 in the 2nd
example, it seems. Surely that is a confusing behaviour, if not bug prone
On Mon, 9 Sep
so *maybe* we'll come back...
On Mon, Sep 9, 2019 at 10:04 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> `require("module") initially explained.
>
> `db.get(SQL) that won't fail but might not return the desired result, so that you end up
> holding the top most object with all the
`require("module") wrote:
> There has to be a better pattern than returning the "foo()" if the baz
> property doesn't exist.
>
> I'm curious what you would want to do with the resulting "foo()" anyway. I
> can imagine a flow where I want "bar", and it doesn't exist it doesn't. I
> cannot imagine
There has to be a better pattern than returning the "foo()" if the baz
property doesn't exist.
I'm curious what you would want to do with the resulting "foo()" anyway. I
can imagine a flow where I want "bar", and it doesn't exist it doesn't. I
cannot imagine wanting the "foo()" in place of it.
Interesting I forgot about that, but it wouldn't cover the "trap here" use
case.
foo().bar ?! what => what : what;
I'd like to forward foo() here
On Sat, Sep 7, 2019, 11:45 Michael Luder-Rosefield
wrote:
> This is getting very reminiscent of my 'forwarding ternary' operator (or
> whatever I
This is getting very reminiscent of my 'forwarding ternary' operator (or
whatever I called it) I suggested a couple of years ago. I believe you were
involved in the discussion, Andrea...!
```
const val = foo() ?!
(x) => x.bar.baz :
someFallbackValue;
```
On Sat, 7 Sep 2019, 10:17 Andrea
To better answer, let's start dropping any direct access and put a payload
in the mix.
As example, in the `foo()?.bar.baz` case, you might end up having `null` or
`undefined`, as result, because `foo().bar` existed, but `bar.baz` didn't.
In the `foo()?.bar?.baz` case, you might end up having
On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi
wrote:
> Indeed I'm not super convinced myself about the "branching issue" 'cause
> `const result = this?.is?.branching?.already` and all I am proposing is to
> hint the syntax where to stop in case something else fails down the line, as
> in
It's
On Fri, Sep 6, 2019, 20:14 Jordan Harband wrote:
> Syntactically marking, in a chain, what you'd like the final value of the
> chain to be, seems interesting - forcing optionality into it seems
> unnecessary, though, if such a syntactic marker could be attached to all
> forms of property
Syntactically marking, in a chain, what you'd like the final value of the
chain to be, seems interesting - forcing optionality into it seems
unnecessary, though, if such a syntactic marker could be attached to all
forms of property access.
Something like: `a.b>.c.d` or `a?.b>?.c?.d` or
Indeed I'm not super convinced myself about the "branching issue" 'cause
`const result = this?.is?.branching?.already` and all I am proposing is to
hint the syntax where to stop in case something else fails down the line,
as in `const result = this.?.is wrote:
> Typically, "dot" expressions
Typically, "dot" expressions navigate through values of different types,
making "type branching" the inevitable next step in those cases (unless you
introduce a common method for further processing for each of those types).
So I'm not sure how ultimately that would be avoided.
On Fri, 6 Sep 2019
> Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura
> a écrit :
>
> 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 will be interpreted.
> In this case, any html page with embedded
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
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
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 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
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 =
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
> Le 5 sept. 2019 à 23:39, Andrea Giammarchi 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
As someone noticed already, the operator should be called eventually
"mouse" operator, as mice is plural and was a misunderstand of mine
On Fri, Sep 6, 2019, 00:54 Andrea Giammarchi
wrote:
> Since somebody asked me already elsewhere about the expected precedence of
> the operator, this would
Since somebody asked me already elsewhere about the expected precedence of
the operator, this would be my answer:
```js
const result = await dbQuery(data) wrote:
> absolutely, I'm working with PostgreSQL these days and indeed for any
> promise/awaited result this pattern looks like a win, and
absolutely, I'm working with PostgreSQL these days and indeed for any
promise/awaited result this pattern looks like a win, and while it's
targeting a limitation of the chaining one, it can be used in various other
cases where knowing the initial result is more important than just falling
back to
Another pattern it could be useful in is with, say, nosql dbs where
something might be an object or id reference:
```
const fooId = foo
wrote:
> Another use case that I believe will be common is the following one:
>
> ```js
> // current state of the art
> const result = dbQuery(data)?.rows ??
Another use case that I believe will be common is the following one:
```js
// current state of the art
const result = dbQuery(data)?.rows ?? 'did it just failed or what?';
// VS the "mice operator"
const result = dbQuery(data) wrote:
> On Thu, Sep 5, 2019 at 2:39 PM Andrea Giammarchi
> wrote:
On Thu, Sep 5, 2019 at 2:39 PM Andrea Giammarchi
wrote:
>
> 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
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
29 matches
Mail list logo
