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
