naveen.chwl at gmail.com (2017-09-23T14:30:08.346Z)
What I don't like is the callback part: `x=>...` for the 2nd operand. This
is too specific. What if you want to forward something to a multi param
call or just use it in the next code statement??? Therefore I think the
power of this proposed operator is limited, compared to a straightforward
ternary, an example of which is given for the use case you gave at the
start:
```js
const
x = getSomething(),
foo =
x ?
(
doSomethingFirst(),
x.doSomething()
) :
doSomethingElse()
```
vs with your proposal:
```js
const
foo =
getSomething() ?!
x => {
doSomethingFirst();
return x.doSomething()
} :
doSomethingElse()
```
which appears to have equivalent code complexity to the ternary equivalent,
at a loss of programmatic power as well as, in my view, understandability.
Do tell me what I'm missing if you don't agree.
What I don't like is the callback part: `x=>...` for the 2nd operand. This is too specific. What if you want to forward something to a multi param call or just use it in the next code statement??? Therefore I think the power of this proposed operator is limited, compared to a straightforward ternary, an example of which is given for the use case you gave at the start: ```js const x = getSomething(), foo = x ? ( doSomethingFirst(), x.doSomething() ) : doSomethingElse() ``` vs with your proposal: ``` const foo = getSomething() ?! x => { doSomethingFirst(); return x.doSomething() } : doSomethingElse() ``` which appears to have equivalent code complexity to the ternary equivalent, at a loss of programmatic power as well as, in my view, understandability. Do tell me what I'm missing if you don't agree. On Thu, 21 Sep 2017 at 18:52 Isiah Meadows <isiahmeadows at gmail.com> wrote: > Can we just let this thread die? The pipeline-based variant is only 2 > tokens more than the shorthand, which provides no additional use. > Additionally, the proposal as a whole is hardly useful outside some > uncommon cases that already have workarounds. > > On Thu, Sep 21, 2017, 07:35 Michael Rosefield <rosyatrandom at gmail.com> > wrote: > >> Oh, yes, but the real benefit here is that it consolidates this as a >> combination of the normal ternary operator and the piping operator; an >> organic synthesis of existing operators as opposed to an entirely new one >> grafted on to the language. >> >> I'd go so far as to call it the 'piping ternary operator' and make it an >> extension of the piping operator proposal. >> >> On Thu, 21 Sep 2017 at 12:22 Michał Wadas <michalwadas at gmail.com> wrote: >> >>> Actual characters are minor issue. There are many unused combinations of >>> "special" characters. Eg. >>> ?> ?: :? ?() @? ?* ?# ?@ @? -? =? ?= (?) etc. >>> >>> >>> >>> On Thu, Sep 21, 2017 at 11:19 AM, Michael Rosefield < >>> rosyatrandom at gmail.com> wrote: >>> >>>> There was a suggestion that came up in my original reddit post that I >>>> think merits discussion here. >>>> >>>> I know one of the main arguments against this new operator is to >>>> prevent needless and confusing language explosion, but u/notNullOrVoid >>>> pointed out that this bears similarity to another operator already under >>>> TC39 consideration, the pipeline-operator ( >>>> https://github.com/tc39/proposal-pipeline-operator). >>>> >>>> My suggestion could then be implemented as follows: >>>> >>>> const foo = getSomething() |> x => x ? dosomething(x) : >>>> doSomethingElse(); >>>> >>>> And this ternary could be simply a pipeline variant: >>>> >>>> const foo = getSomething() ?> x => dosomething(x) : doSomethingElse(); >>>> >>>> That reads much clearer and also takes care of the syntactically >>>> invalid ?! formularion. >>>> >>>> On Wed, 20 Sep 2017 at 14:22 Naveen Chawla <naveen.chwl at gmail.com> >>>> wrote: >>>> >>>>> As your example shows, for loops can be reduced to array reduction >>>>> function calls. `if` `else`s can be represented by ternaries. >>>>> >>>>> `while` loops aren't so straightforward but can be factored into >>>>> single function calls. They are less common anyway. >>>>> >>>>> I find single expressions listed as `(a, b, c)` more readable than >>>>> code blocks who eventually evaluate to a single value each. >>>>> >>>>> So, even if `do` expressions were introduced into ES, I would avoid >>>>> using them as much as I could, unless it were really smarter and more >>>>> readable to use them than any of the alternatives >>>>> >>>>> On Wed, 20 Sep 2017 at 16:11 T.J. Crowder < >>>>> tj.crowder at farsightsoftware.com> wrote: >>>>> >>>>>> On Wed, Sep 20, 2017 at 11:28 AM, Naveen Chawla < >>>>>> naveen.chwl at gmail.com> wrote: >>>>>> > >>>>>> > The comma operator seems to make the `do` concept redundant, at >>>>>> > least for me. >>>>>> >>>>>> No, not at all. Again: With the comma operator, you can't use >>>>>> *statements*, only expressions. With the `do` expression, you can use >>>>>> actual statements: >>>>>> >>>>>> ```js >>>>>> const x = do { >>>>>> for (const x of getTheThings()) { >>>>>> if (x.id == something) { >>>>>> x.foo; >>>>>> } >>>>>> } >>>>>> }; >>>>>> ``` >>>>>> >>>>>> ...which is basically: >>>>>> >>>>>> ```js >>>>>> const x = getTheThings().find(x => x.id == something).foo; >>>>>> ``` >>>>>> >>>>>> ...except it doesn't throw if `find` returns `undefined`, and isn't a >>>>>> series of function calls. >>>>>> >>>>>> `do` expressions are basically to address overly-complex conditional >>>>>> expressions and IIFEs. >>>>>> More: >>>>>> https://gist.github.com/dherman/1c97dfb25179fa34a41b5fff040f9879 >>>>>> >>>>>> -- T.J. Crowder >>>>>> >>>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> es-discuss at mozilla.org >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170921/637f5a18/attachment.html>