|
|
|
|
|
by sgbeal
837 days ago
|
|
> Do programming languages really need any of these two? "Need," no, but when this distinction is useful, it's really useful. There's no other way (in JS, at least) to distinguish between "no value set" and "it has been set but not to a real value." A common example is inbound JSON data: when checking for property X, it's "undefined" if it's not set at all, and "null" if the property was set to null via JSON. JSON doesn't have "undefined," and uses "null" in that context. That distinction can be used to assign a non-value (null) to a property name which might otherwise be inherited via the prototype chain and cause confusion. Hmmm... that example suggests, because the engine will have native JSON support, that i'll _need_ a "null" value whether or not i've also got an "undefined" value. |
|