tj.crowder at farsightsoftware.com (2017-02-01T18:25:24.186Z)
The chief advantage I see to doing this with syntax is
short-circuiting. Otherwise, you could use a helper function to
achieve `if (valueIn(object.property.secondProp, 'a', 'b'))` quite
readily. Short-circuiting makes this interesting, though I worry about
it pulling its syntactic weight.
If the mechanism did short-circuiting (lazy evaluation), then this
(using your syntax for now)...
```js
if (object.property.secondProp === (foo() : bar())) {
// do something
}
```
...wouldn't call `bar` if the property's value matches the
return value of `foo` (just like `x === foo() || x === bar()`
wouldn't).
That being the case, the syntax would have to be visually distinct
from an array (as yours is) to avoid confusion, while still supporting
arbitrary expressions and, ideally, spread syntax.
I notice that you've used a relational operator (strict equality, in
this case) and then special syntax following it, rather than (say) `if
(x anyof ('a', 'b'))`. Is it your intention that other operators would
work with it too? `if (x > (a : b : c))`? (Rather than `if (x > a || x > b || x > c)` or `if (x > Math.min.call(Math, a, b, c))`.)
Also, you've used `||` in your example. What about `&&`? Suppose I
want to make sure that `x` is greater than all three values in `a`,
`b`, and `c`? I wonder if we could keep the syntax general enough to
handle both cases.
On syntax: I'm with Ryan about not being keen on the `(x : y : z)`
syntax. Also, given that the values could be arbitrary expressions
nested arbitrarily deep, it seems like the `:` after the first value
is a bit late to be telling the parser what's going on. I wonder if we
could do it earlier. (Also, `:` isn't a natural list delimiter to my
mind...)
Hmmm, taking the `||` vs. `&&` into it, one idea would be to put the
logical operator immediately (other than whitespace) following the
opening paren:
```js
if (x === (|| 'a', 'b')) {
```
Equivalent to (but x is only evaluated once):
```js
if (x === 'a' || x === 'b')
```
and
```js
if (x > (&& foo(), bar())) {
```
Equivalent to (but x is only evaluated once):
```js
if (x > foo() && x > bar())
```
(Starts feeling a bit like Lisp.)
I can't help but think: At a high level, operators are just functions
with special syntax, multiple dispatch, and lazy operand evaluation.
Setting aside the multi-dispatch aspect, what if we...had a way to
lazily evaluate function arguments? It sounds simple, but it gets
complicated *fast* for situations like this where the argument list
varies in length. But potentially quite powerful, and plays into
[operator overloading](https://esdiscuss.org/topic/operator-overloading-proposal)
should that happen...
-- T.J.tj.crowder at farsightsoftware.com (2017-02-01T18:24:36.347Z)
The chief advantage I see to doing this with syntax is
short-circuiting. Otherwise, you could use a helper function to
achieve `if (valueIn(object.property.secondProp, 'a', 'b'))` quite
readily. Short-circuiting makes this interesting, though I worry about
it pulling its syntactic weight.
If the mechanism did short-circuiting (lazy evaluation), then this
(using your syntax for now)...
```js
if (object.property.secondProp === (foo() : bar())) {
// do something
}
```
...wouldn't call `bar` if the property's value matches the
return value of `foo` (just like `x === foo() || x === bar()`
wouldn't).
That being the case, the syntax would have to be visually distinct
from an array (as yours is) to avoid confusion, while still supporting
arbitrary expressions and, ideally, spread syntax.
I notice that you've used a relational operator (strict equality, in
this case) and then special syntax following it, rather than (say) `if
(x anyof ('a', 'b'))`. Is it your intention that other operators would
work with it too? `if (x > (a : b : c))`? (Rather than `if (x > a || x
> b || x > c)` or `if (x > Math.min.call(Math, a, b, c))`.)
Also, you've used `||` in your example. What about `&&`? Suppose I
want to make sure that `x` is greater than all three values in `a`,
`b`, and `c`? I wonder if we could keep the syntax general enough to
handle both cases.
On syntax: I'm with Ryan about not being keen on the `(x : y : z)`
syntax. Also, given that the values could be arbitrary expressions
nested arbitrarily deep, it seems like the `:` after the first value
is a bit late to be telling the parser what's going on. I wonder if we
could do it earlier. (Also, `:` isn't a natural list delimiter to my
mind...)
Hmmm, taking the `||` vs. `&&` into it, one idea would be to put the
logical operator immediately (other than whitespace) following the
opening paren:
```js
if (x === (|| 'a', 'b')) {
```
Equivalent to (but x is only evaluated once):
```js
if (x === 'a' || x === 'b')
```
and
```js
if (x > (&& foo(), bar())) {
```
Equivalent to (but x is only evaluated once):
```js
if (x > foo() && x > bar())
```
(Starts feeling a bit like Lisp.)
I can't help but think: At a high level, operators are just functions
with special syntax, multiple dispatch, and lazy operand evaluation.
Setting aside the multi-dispatch aspect, what if we...had a way to
lazily evaluate function arguments? It sounds simple, but it gets
complicated *fast* for situations like this where the argument list
varies in length. But potentially quite powerful, and plays into
[operator overloading](https://esdiscuss.org/topic/operator-overloading-proposal)
should that happen...
-- T.J.
The chief advantage I see to doing this with syntax is short-circuiting. Otherwise, you could use a helper function to achieve `if (valueIn(object.property.secondProp, 'a', 'b'))` quite readily. Short-circuiting makes this interesting, though I worry about it pulling its syntactic weight. If the mechanism did short-circuiting (lazy evaluation), then this (using your syntax for now)... ```js if (object.property.secondProp === (foo() : bar())) { // do something } ``` ...wouldn't call `bar` if the if the property's value matches the return value of `foo` (just like `x === foo() || x === bar()` wouldn't). That being the case, the syntax would have to be visually distinct from an array (as yours is) to avoid confusion, while still supporting arbitrary expressions and, ideally, spread syntax. I notice that you've used a relational operator (strict equality, in this case) and then special syntax following it, rather than (say) `if (x anyof ('a', 'b'))`. Is it your intention that other operators would work with it too? `if (x > (a : b : c))`? (Rather than `if (x > a || x > b || x > c)` or `if (x > Math.min.call(Math, a, b, c))`.) Also, you've used `||` in your example. What about `&&`? Suppose I want to make sure that `x` is greater than all three values in `a`, `b`, and `c`? I wonder if we could keep the syntax general enough to handle both cases. On syntax: I'm with Ryan about not being keen on the `(x : y : z)` syntax. Also, given that the values could be arbitrary expressions nested arbitrarily deep, it seems like the `:` after the first value is a bit late to be telling the parser what's going on. I wonder if we could do it earlier. (Also, `:` isn't a natural list delimiter to my mind...) Hmmm, taking the `||` vs. `&&` into it, one idea would be to put the logical operator immediately (other than whitespace) following the opening paren: ```js if (x === (|| 'a', 'b')) { ``` Equivalent to (but x is only evaluated once): ```js if (x === 'a' || x === 'b') ``` and ```js if (x > (&& foo(), bar())) { ``` Equivalent to (but x is only evaluated once): ```js if (x > foo() && x > bar()) ``` (Starts feeling a bit like Lisp.) I can't help but think: At a high level, operators are just functions with special syntax, multiple dispatch, and lazy operand evaluation. Setting aside the multi-dispatch aspect, what if we...had a way to lazily evaluate function arguments? It sounds simple, but it gets complicated *fast* for situations like this where the argument list varies in length. But potentially quite powerful, and plays into [operator overloading](https://esdiscuss.org/topic/operator-overloading-proposal) should that happen... -- T.J. On Wed, Feb 1, 2017 at 5:50 PM, kdex <kdex at kdex.de> wrote: > I actually don't think this is worth pursuing, as it can easily be > implemented > by libraries once we solve operator overloading, without adding new syntax: > > `` > if (1 < [2, 3]) > `` > > Am 01.02.2017 um 18:12 schrieb Ryan Birmingham: > > I have a handfull of questions on this proposal as well: > How would your proposal look with three or four things to check against? > Would the collection of things to check against be a variable? > Would this be syntactic sugar to the array includes method, or would this be > something entirely new? > > -Ryan Birmingham > > On 1 February 2017 at 12:03, Felipe Nascimento de Moura > <felipenmoura at gmail.com> wrote: >> >> I see... >> we could perhaps think on some other approach. >> >> What about: >> if (obj.prop.prop ?== 'a' : 'b') >> >> This way, we have "?==", which is not too chocking once we already got >> "!==", and this kinda prepares the engine to deal with the next values as >> part of the comparison. >> Also, feels familiar due to " something ? 'a' : 'b' " >> >> Personally, I don't feel that comfortable with this syntax. >> We could think on different a token as well >> >> if (obj.prop.prop === (? 'a' : 'b')) // feels like a ternary, but without >> the first statement >> if (obj.prop.prop === ('a' | 'b'))) // could break the web once it is >> already valid syntax (although not very used) >> if (obj.prop.prop === ('a' :: 'b')) // perhaps a double colon >> >> Anyways, open for suggestions :) >> >> >> >> >> On Wed, Feb 1, 2017 at 2:48 PM Ryan Birmingham <rainventions at gmail.com> >> wrote: >>> >>> I like the idea, and I generally agree that your proposal would increase >>> readability, but I'm not a fan of the colon in parenthesis. >>> In this context, the colon looks like it should represent a member >>> assignment of 'b' to 'a'. >>> >>> >>> -Ryan Birmingham >>> >>> On 1 February 2017 at 11:27, Felipe Nascimento de Moura >>> <felipenmoura at gmail.com> wrote: >>>> >>>> Hi. >>>> >>>> I wonder if there is already a proposal for such thing or if it would be >>>> something interesting to be proposal: >>>> >>>> The motivation: >>>> Let's say you have an object whose property you want to compare to 'a' >>>> or 'b': >>>> >>>> ``` >>>> if (object.property.secondProp === 'a' || object.property.secondProp === >>>> 'b') { >>>> // do something >>>> } >>>> ``` >>>> >>>> The proposal: >>>> Now, with this syntax you would be able to perform such comparisons in a >>>> much simpler, better to read approach: >>>> >>>> ``` >>>> if (object.property.secondProp === ('a' : 'b')) { >>>> // do Something >>>> } >>>> ``` >>>> >>>> And with the advance of the Optional Chaining Operator proposal, it >>>> would get even better, like so: >>>> >>>> ``` >>>> // this: >>>> if (object && >>>> object.property && >>>> (object.property.secondProp === 'a' || >>>> object.property.secondProp === 'b')) { >>>> // ... >>>> } >>>> >>>> // becomes this: >>>> if (object?.property?.secondProp === ('a' : 'b')) { ... } >>>> ``` >>>> >>>> Alternatives: >>>> I do know that we could accomplish that with other techniques, like: >>>> >>>> ``` >>>> ['a', 'b'].includes(object.property.secondProp) >>>> ``` >>>> >>>> I just think it might be counterintuitive and having a syntax for a >>>> "short comparing" would be better for reading and understanding. >>>> >>>> Would make ternary comparison even shorter, too: >>>> >>>> ``` >>>> let currentState = object.property.status === ('fail' : 'ok') ? 'done' : >>>> 'doing' >>>> ``` >>>> >>>> Please let me hear your thoughts on that :) >>>> >>>> Regards. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >