On Tue, Jun 12, 2012 at 10:17 PM, David Herman <[email protected]> wrote: > On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote: > >> My point still stands. Being "undefined"-specific is arbitrary. >> CoffeeScript could have been "undefined"-specific; they were >> "undefined" + "null"-specific, which I believe makes more sense. > > Can you make the full argument? I'm genuinely undecided on this question, and > having trouble deciding on the criteria.
"undefined" and "null" share a lot of behavior that other falsy values don't have. The most critical one is to throw a TypeError on some occasions, including when invoking the abstract ToObject operation. Besides, it often has a similar meaning: I have seen in a lot of code a de-facto standard wherein null is used to indicate a value that is voluntarily undefined. You can see this pattern all over node.js code, for instance. This lets the user know when a parameter was meant to be set to nothing, and when we should use a default parameter instead. Harmony's default parameters will make this easier, while letting a null value through -- which will make this pattern even more common. On the other hand, we often want to react in a certain way if the parameter is not set, either because it was not supplied or because it was set to null. Besides, the null value can be obtained from the standard library, when calling certain methods. Object.getPrototypeOf(...), string.match(...), even calling the toJSON method of a Date can return null. Having a way to deal with those return values by providing a default value would be nice. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
