Open DavidBruant opened 11 years ago
Words from the language creator:
Java has null but only for reference types. With untyped JS, the uninitialized value should not be reference-y or convert to 0.
This makes sense to me. Keeping the issue open nonetheless and I'll write something about it one day. It seems like an interesting piece of information to be aware of if designing a compile-to-JS language.
I disagree with that. null
is confirmed lack of value, undefined
is unknown value (never defined).
In data oriented projects I work with, there's clear distinction between those two types.
Ah, so JavaScript values are Maybe Maybe T
s. undefined
is Nothing
, null
is Just Nothing
, and actual values are Just Just v
. I've never thought of it like that.
@michaelficarra undefined
indicates an absence or a lack of initialization. null
values indicate an intentionally empty value on a variable that has been initialized. I find this is pretty reasonable in the context of this language.
This shouldn't be a regret, but a win for the language. Having both undefined
and null
makes it so much easier to make those 3 in 1 accessor methods (setter, getter and deleter) discriminating if the value parameter is undefined
(getter), null
(deleter) or some primitive or object (setter). Example: https://gist.github.com/azder/5559489
Some how all other languages do just fine without distinction not existing values and intentionally emptied values. If one for some reason wants to empty a value but signify the fact that it exists never the less usually new special Type / Constants are used in other languages that do job well, also discouraging that pattern.
So sure there is a difference between null
and undefined
, but that's exactly an issue adds complexity of differentiating things that don't need to be different.
The same argument can be used on the reverse: JavaScript has both null
and undefined
and does just fine with that distinction. The developers don't, out of probably subjective reasons.
Now,
usually new special Type / Constants are used in other languages that do job well
special type like... lets see.... undefined
type in JavaScript or a constant like the undefined
(in ES5 strict though) ???
I'd argue that even those languages with only null
would've been better off without it (using Null Object Pattern) or at least implementing safe navigation operator.
null
and undefined
should've been made into Null Object Pattern-ed objects.
My point is Null objects are quite exotic, JS makes them mainstream and more things to comprehend is rarely makes things simpler.
Simple languages produce complex frameworks, complex languages produce simple frameworks. It is only a matter of subjective preference where you want the complexity in.
And why are Null objects exotic, but CONSTANTS not? Simply because they don't teach you that pattern at school.
So, exotic is only what you don't quite understand. And not understanding null
and undefined
should be a greater regret than having them both ;)
Take a look at lua very similar to JS with much less misfeature than in JS (including this one). Does great without Null objects or special Constants etc.. Very simple designed such that you don't need to have that distinction. It's just a good language design! For example clojure data structures are immutable (like strings in JS) but language designed such that it's just feels great, in contrast try writing JS without mutations and it will be a pain. My point is sure every feature can be justified, although some can be just simplified.
Either way I don't feel like continuing this discussion as it clearly isn't taking us anywhere. Claiming that only JS got it right is just ridiculous, all good ideas are usually adopted by new languages that come after, I'm afraid this one does not seems to pick up.
@Gozala Looking from right angle we can say that concept of null
and undefined
exists in most languages.
The differences are:
undefined
value.undefined
as a value to property or variable.While I find 1 as expected behavior, which I like in JavaScript and definitely wouldn't change, 2 is indeed controversial thing, we're probably questioning.
I think it would be more logical if assignment of undefined
would have no effect, but deleting the variable would clear it's property, so:
var x; // x === undefined
x = 3;
x = undefined; // No effect, throw in strict mode
delete x; // Brings back x === undefined
Currently it's exactly opposite, delete on local variable has no effect and throws in strict mode, and assignment of undefined
brings back undefined state to local variable.
Same way with properties, but here delete works as intended, it clears property which then fallbacks to value of same property of its object's prototype.
However JavaScript allows us also to assign undefined
to property, through that we can shadow lower prototype value with undefined
. Looks interesting, but honestly I don't see a real use case for that, it would be totally fine if we could shadow properties only with null
and other real values, and assignment of undefined
would have no effect as I demonstrated above with local variables.
So reassuming both are needed, what's controversial is that undefined
works as any other value and that's confusing.
There are languages where nil
is used in cases where JS uses either null
or undefined
(for example take a look at Lua). Works great and no one really misses distinction between "not yet existing" and "not existing value". All I'm saying JS could be a lot simpler if it did the same.
Also please do not explain me difference between null
& undefined
I know it very well, I just think there's a very little value to it to justify it's existence and added complexity to a language.
That being said, I'm happy(more honestly sad) to see so many people be so passionate about this (miss)feature.
@Gozala in data related logic it's sometimes important to know, whether value is intentionally null
or has was it never defined.
Forked out of #25. JavaScript has both
undefined
andnull
while only one could be enough.