On Apr 13, 2011, at 9:21 PM, Kyle Simpson wrote:
>> First, making : optional introduces a dangling-else ambiguity:
>>
>> x = a ? b ? c : d;
>>
>> This could be (x = a ? (b ? c : d)) or (x = a ? (b ? c) : d).
>>
>> True, if-else already has this (traditional in C-based languages) ambiguity,
>> "resolved" by associating : with the inner ? and so requiring the programmer
>> to use braces if the other association is wanted, or in general just to
>> avoid trouble. But why should we add more of the same kind of ambiguity,
>> given the benefit of hindsight?
>
> 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'm also not sure b is falsy but not undefined in practice. It seems
>> contrived to want a numeric value sometimes, and undefined others. IOW,
>>
>> var a = (b > 5) ? b : undefined;
>>
>> looks like a bug that will result in "undefined" or NaN values propagating
>> via a, some of the time, into other numeric or number to string expressions.
>> It looks like a mis-coded "min" against 5.
>
> In my code, one example where I often use a pattern of something either being
> undefined or having a real value, is in "options" object configurations, like
> when you pass an options hash to a function. For instance, if a property is
> omitted, or it's present but is `undefined`, then it's taken to have not been
> set at all, and thus is either ignored, or in some cases is defaulted to some
> other value. OTOH, if it's set to an actual numeric value, then the numeric
> value is of course used.
>
> The value `null` is another common value used for the purpose of indicating
> "not set" or "ignore this property". I tend to not like that quite as much,
> since `typeof null == "object"` (which can be confused with other types if
> you're not careful) where as `typeof undefined == "undefined"` unambiguously.
>
> There's also been a few cases where I've distinguished between a value being
> "undefined" (aka, "not set") and the value being "null" (aka, set
> deliberately to empty). For instance, if you pass in an option with the value
> as `undefined`, that means "not set" and it's ok to grab and use a default
> value for that option. But if you explicitly pass in an option with value
> `null`, that means "disable or ignore me" and don't use the default value. I
> don't use "false" in this case, as it's easy to mistakingly coerce that to a
> 0 numeric value.
In sum, this sounds like an argument against ? as infix operator (implied :
undefined).
> In any case, `null` vs. `undefined` aside, having sugar for this pattern
> would just be nice:
>
> 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, but
you want (number | undefined), a type union. If any consumer fails to
discriminate using typeof, they'll get undefined which coerces to NaN as number
(to 0 as integer). Bad times.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
