I'm not sure I see how this is really introducing an additional
ambiguity?
It is obviously introducing an ambiguity where none exists today. ?: is
indivisible, unlike if vs. if else.
I was referring to no additional visual ambiguity inside the ?: with respect
to operator precedence and how to interpret a chain of nested ?:, as
compared to doing the same task if `:` is optional.
a ? b ? c : d ? e ? f : g : h ? i : j : k
==>
a ? (b ? c : (d ? (e ? f : g) : (h ? i : j))) : k
Firstly, that code has no *real* ambiguity, because operator precedence
tells us how those implied () sets disambiguate it.
Secondly, in my opinion, the visual "ambiguity" of it is not made any more
burdensome (and is even perhaps SLIGHTLY *clearer*) by adding () sets to
disambiguate where you want optional `:`, such as this example (same as
above, but where `g` and `j` are omitted as placeholders for implied
`undefined`):
a ? b ? c : d ? (e ? f) : (h ? i) : k
==>
a ? (b ? c : (d ? (e ? f : undefined) : (h ? i : undefined))) : k
Moreover, this code wouldn't have any actual ambiguity even if you omitted
those two sets of () in the original. It would still be a valid expression,
with a different (but still unambiguous) interpretation:
a ? b ? c : d ? e ? f : h ? i : k
==>
a ? (b ? c : (d ? (e ? f : (h ? i : k)) : undefined)) : undefined
Developers who chain/nest ?: together are already familiar with how and when
they have to use () to disambiguate, and the rules for what happens when
they don't, and it seems like exactly the same effort for them to do so if
implied `: undefined` were something they wanted to/could leverage.
In sum, this sounds like an argument against ? as infix operator (implied
: undefined).
I'm sorry, I'm lost by this statement. I don't understand on what basis you
conclude that I just argued against the very thing I'm asking for. Can you
elaborate at all?
var opts = {
doX: (someX > 0 && someX < 10) ? someX , // leaving off the `:
undefined` (or `: null` if you prefer)
doY: (someY > 0 && someY < 1) ? someY // ditto
};
Sorry, I think this is a hazardous pattern. "doX" suggests a boolean
value,
How is
doX = (someX > 0 && someX < 10) ? someX
more suggestive of a "boolean" value than is
doX = (someX > 0 && someX < 10) ? someX : undefined
Or, put another way, how are either of them suggestive of a boolean value
result? Unless you mean simply the name "doX" being suggestive of "do" or
"do not" (probably a poor name choice for my example), I don't see how
either code snippet itself implies a boolean value result.
As far as I am concerned, they both clearly indicate selecting a value (type
irrelevant) based on a boolean test. The implied part hides one of the
variable choices, yes, but I don't see how that suggests an entirely
different type of operation/result?
but you want (number | undefined), a type union.
I'm not sure if you're arguing against:
a) the pattern of having an `undefined` value in a variable when "unset",
that otherwise stores numbers when it's "set"; OR
b) the implied `: undefined`
If (a), this was a long held pattern long before I ever wrote my first line
of JavaScript. Moreover, it's far more common today on the greater web than
any code I've ever written. I'd argue it's pretty close to a de facto
pattern at this point, so I'm not sure what the point is in using that
argument to contradict my request for an implied `: undefined`. Moreover,
this code sample I gave is only one such example. If it irks you that much,
I'm sure I could find other examples to illustrate. But, I'm not really sure
how that helps or hinders the process.
If (b), I'm not sure what the type union for "set" vs. "unset" has to do
with the request for implied `: undefined`? These seem like different
discussions altogether.
It sounds like you're basically saying either that my idea is very niche and
thus irrelevant to consider, or that the supporting reasoning behind the
idea is flawed/bad code, and thus the idea is necessarily flawed/bad. Is it
either, both, or neither of those that you are suggesting?
If any consumer fails to discriminate using typeof, they'll get undefined
which coerces to NaN as number (to 0 as integer). Bad times.
First of all, I'm talking about code where I am the consumer, so I take care
to make sure the proper checks are done.
Secondly, criticizing the pattern as a substitute for criticizing the
idea/proposal is a non sequitur, or orthogonal at best. Completely ignoring
the implied `: undefined` for a moment, there's plenty of other ways that a
variable might end up with a proper (numeric) value in the "set" state, and
an `undefined` value in the "unset" state. It is therefore a granted that,
regardless of whether implied `: undefined` were ever to be considered valid
or not, safely checking variables with proper understanding of type coercion
is a must.
--Kyle
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
