On Apr 14, 2011, at 12:00 AM, Kyle Simpson wrote: >> It's also not obviously a good non-hard case to burn into the grammar. > > What is non-hard about saying that, in the processing of any ?: expression, > if the ? is present but the : is not found where it is expected, then the : > is implied and is always `: undefined` (or `: void 0`, if you prefer)? > Perhaps I'm missing it, but I really don't see how it's any harder than that > alone.
Please read http://en.wikipedia.org/wiki/Hard_cases_make_bad_law -- I think you are misreading "hard" in "hard case". >> The name "doX" connotes boolean. > > OK, so your complaint is about the bad name I gave that variable. Fine. > Agreed. "do" was a bad word for a non-boolean. s/do(X|Y)/coord$1. Variables > names in examples aside, the point of the example (the operator usage) should > be clear. Not sure why it isn't? I wasn't picking on the name in isolation. It was pretty clearly influenced by the type it holds being a union of undefined with number, which is the underlying bone of contention. That is not merely a matter of naming. > [snip way too much, to avoid endless fisking and counter-fisking] >> A hazardous pattern is no argument for syntactic sugar. At best you have a >> minority use-case. At worst, it's a latent bug. > > Are you suggesting that the ability to assign `undefined` to a variable or > property is so bad that it's actually a bug in the language? The same problem applies with any bottom type in a dynamic language. I do think hoisting of var is a bug in the language because it enables what looks like use-before-set errors and makes for more undefined inhabitation of vars that would otherwise by monotyped and in smaller scopes, but that is water under the bridge by almost 16 years. What is not water under the bridge is burning syntax and adding another dangling-else form on this peculiar case, which has only come up now and still seems like a very obscure case, never mind CoffeeScript (where it may be even more obscure, even though served -- again, CS lacks the ?: operator so it can be different, we can't just harvest bits of syntax without careful validation, etc. etc.). Encoding undefined into an expression as an implicit result, only to be stored in a variable so you can treat that variable as if it were never set? It looks like a hard case to me. More, it looks like a hard case with type confusion risk. Even if you manage to avoid undefined-as-number bugs, having to write ": undefined" or similar out the long way, if you truly can't use &&, is better on balance than making : optional after ? in the core language we all have to spec, implement, teach, and share. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
