I don't think this feature is worth all this discussion or time, which is why I
haven't said very much. But I don't like the idea.
It *is* ambiguous, in the sense that if you wrote the grammar in the natural
way it would be an ambiguous grammar, so you have to rewrite the grammar in
such a way as to force precedence rules to disambiguate.
But more importantly, I don't believe it's an important enough case to be worth
syntactic support for, especially since `undefined' isn't always the default
value you want to use.
And FWIW: Racket actually moved *away* from supporting one-armed `if' -- they
disabled it somewhere around v4, I think -- because experience showed that the
cases where it was useful were outnumbered by the cases where it caused
accidental leakage of `undefined' values, which is the moral equivalent of a
NullPointerException.
Dave
> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
