Kyle's proposal. Dave -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
"Dmitry A. Soshnikov" <[email protected]> wrote: On 14.04.2011 1:23, David Herman wrote: > 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. > Are you talking about Kyles proposal or about my initial? I remind, my initial proposal was exactly about "?." operator to avoid this noisy and completely useless: if (foo.bar) { if (foo.bar.baz) { if (typeof foo.bar.baz.quax == "function") { foo.bar.baz.quax("value") } } } and to replace it with: foo.bar?.baz?.quax("value"); we can adopt it only for property accessor, nor for a variable binding directly (which seems doesn't create ambiguity). I.e. only for: foo?.bar but not for: foo? Dmitry. > 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 `: nu ll` 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 `undef ined` 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_____________________________________________ 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
