Which has a comment explaining that it is an optimisation based on the idea that "defined variables are faster than not-defined ones" - I have no idea if that is true or not.
"undefined in the jQuery code is actually an undefined parameter of a function wrapping the whole code"
Presumably if you have your own local undefined that is guaranteed to be undefined then you are safe from someone else setting it to be something silly.
If you have to guard against someone doing something silly, then you are never safe. The problem is not the language at that point, it's the environment.
To err is human -- you're never safe. Even if we say people are the root of the problem, fixing their fundamentally imperfect nature is currently beyond the capabilities of science, whereas doing something like enforcing constants at a language level is not. Education will reduce, but not eliminate, the chance of making such a mistake.
It also allows minifiers to minify that "undefined" variable. Not that i think it's good practice to use those kind of hacks that gzip compression makes obsolete :P
It does happen. I worked with one team several years back that had inherited some particularly bad JavaScript code, and this was an issue they ran into several times. They ended up having to audit all of the code for nonsense like this before they could proceed with actual work.
Exactly. I'm tired of these alarmist articles with "you must do this" solutions to non-existent problems. I always think "oh, shi-" before I realize the problem affects exactly no-one.
> […] if you throw your scripts out there on the web you've got to expect that somewhere, at some time someone is going to do it […]
And then it will be that persons' problem. Their code would be wrong, not mine. By not making sure my code works when undefined is broken, I would be helping them to realize they have a possible bug in their codebase and that they need to fix it.
This is one among many serious, and unjustifiable, flaws with JavaScript. It's the kind of issue that should never even arise with anyone's code in the first place, regardless of who wrote the code, because the language and its implementations should not allow it to happen.
And, yes, we know that other languages have flaws, too. But aside from perhaps PHP, the flaws in other languages are almost never as outright stupid as they are with JavaScript.
>And, yes, we know that other languages have flaws, too. But aside from perhaps PHP, the flaws in other languages are almost never as outright stupid as they are with JavaScript.
Citation needed. There are tons of languages with huge fucking flaws to blow your code and kick your dog.
PHP and Javascript are relatively harmless (if a little brain damaged). At least you don't get buffer overflows using them.
You think C++ has a better design, for example? People forgot how bad Python used to be, pre 2.4?
No, the OP was correct - other languages have flaws but nowhere near the level of Javascript. You pick on C++ which is a design by committee monstrosity but it is nowhere near as braindead as Javascript. I mean, C++ allows you to include other code! C++ doesn't allow you to redefine the constants of the language. Actually, C++ has constants!
Nope, as much as I like to rail against the sins of C++, it is a paragon of design virtue next to JS. I've been programming for three decades now and JS is the worst language I have ever seen. I use JS a lot in my day job and it has parts I really like (object constants, for example) but really, as a piece of language design it is really the pits.
That's not really a C++ construct, as much as it is a hold-over from C, kept around to retain compatibility with existing code.
If you're writing new C++ code, you're in no way forced to use it. You can use constants or inline functions to achieve the same result in almost all cases.
Isn't this whole issue just a minor version of the problem Ruby has with monkeypatching? The fact that a Ruby guy can define `method_missing` to allow for bare strings shows how Ruby is cool (though you should never do that), but the fact that you can redefine `undefined` in JS shows how JS is stupid (despite the fact that you should never do that). I don't understand the dichotomy.
People don't typically inject frequently changing, unvetted advertising code into their ruby runtimes. Generally, the most frequently that the ruby code in your runtime changes is each deploy.
Granted, but that's an incidental problem, not one arising from JS being a bad language. Also, I highly doubt there is much advertising code that changes the value of "undefined" - certainly not any I've encountered.
This really boils down to "my code won't act the same way if I give unfettered access to my environment to unvetted code" which is true in almost any situation. If you're having problems because "undefined" is being redefined, you have bigger and more fundamental problems. There are a lot of bad things about JS, but this is not one of them - its overly nitpicky and completely unfair. This same capability (of being able to redefine almost anything) is lauded as part of Ruby, but when it could theoretically cause any easy-to-avoid problem in JS, it's just more proof that JS is a shitty language.
Sorry if I'm coming across as combative - I don't mean to. I just think this whole snide criticism of JS for every little thing is silly and unhelpful, and has more to do with a superiority complex than actual technical issues.
In general you are correct, redefinition in Ruby can be abused, but it isn't so easy to abuse 'nil' in Ruby as it is to abuse 'undefined' in Javascript.
In Ruby, nil, is a keyword so you can't assign to it nor can you use it as a method parameter.
There are a lot of potential pitfalls in coding JavaScript. Redefining undefined is only one of many.
One of the nice things about JavaScript is that it gives you the ability to accomplish things many different ways, but if someone uses that to shoot themselves in the foot then that is something they need to correct.
I tend to read these sorts of articles as "don't do stupid things". Who in their right mind would name an argument undefined? (or use a library by someone who would do so) The operative sentence in the article to me is "can be avoid if you understand how it works". On an unrelated note I'm not sure if that's a typo or a pun.
> Let's say someone is using your library within that function and you reference undefined. You get the string "oops". Oops indeed.
That is incorrect. It might be correct if the word 'library' was replaced by 'code snippet' to indicate a copy-and-paste-of-your-code issue. But if you've created a library then your functions are over in some other file, where `typeof undefined === "undefined"`.
The proper attitude here is the same as the Python attitude towards not having `private` attributes: "If some other programmers want to do something crazy with my code, that's their prerogative. If it blows up in their faces, that's their problem."
I used to believe this, but I now realise it's insufficient when building large apps. Upgrading the version of Django (or indeed Rails) you depend on requires a comprehensive testsuite and involves changes to your code. Upgrading the version of Wicket you depend on is easy because the framework is able to enforce that you only access the attributes you're meant to, only subclass things that are designed to be extended, etc.
I find the cult of 'oh my god you can redefine undefined' hilarious. Yes, you can. You can also redefine Array, Object, and so on. If you're writing a script to intentionally disrupt a system, for(;;); will also do. This doesn't happen in sane environments, so it really isn't a problem.
The Crockford quote (characteristically dogmatic, to the effect of 'void means something different in JS than in Java, so AVOID VOID!') is also a kicker.
The worst thing about undefined is not its mutability but that it exists in the first place. Trying to retrieve a non-existent attribute should throw an error by default, not fail silently.
33 comments
[ 6.0 ms ] story [ 79.5 ms ] threadThis seems like a solution in search of a problem.
https://github.com/Searle/mothello/blob/c31fc57bedd666e9da34...
I wonder if this counts as redefining undefined though!
The comment also suggests that jQuery does this, which seems to be true as explained in this link:
http://stackoverflow.com/questions/7141106/undefined-variabl...
"undefined in the jQuery code is actually an undefined parameter of a function wrapping the whole code"
Presumably if you have your own local undefined that is guaranteed to be undefined then you are safe from someone else setting it to be something silly.
Edit: The jQuery sources are all wrapped in:
If someone redefined undefined and it causes a problem - too bad! Some problems are just too stupid to worry about.
And then it will be that persons' problem. Their code would be wrong, not mine. By not making sure my code works when undefined is broken, I would be helping them to realize they have a possible bug in their codebase and that they need to fix it.
And, yes, we know that other languages have flaws, too. But aside from perhaps PHP, the flaws in other languages are almost never as outright stupid as they are with JavaScript.
Citation needed. There are tons of languages with huge fucking flaws to blow your code and kick your dog.
PHP and Javascript are relatively harmless (if a little brain damaged). At least you don't get buffer overflows using them.
You think C++ has a better design, for example? People forgot how bad Python used to be, pre 2.4?
Nope, as much as I like to rail against the sins of C++, it is a paragon of design virtue next to JS. I've been programming for three decades now and JS is the worst language I have ever seen. I use JS a lot in my day job and it has parts I really like (object constants, for example) but really, as a piece of language design it is really the pits.
If you're writing new C++ code, you're in no way forced to use it. You can use constants or inline functions to achieve the same result in almost all cases.
This really boils down to "my code won't act the same way if I give unfettered access to my environment to unvetted code" which is true in almost any situation. If you're having problems because "undefined" is being redefined, you have bigger and more fundamental problems. There are a lot of bad things about JS, but this is not one of them - its overly nitpicky and completely unfair. This same capability (of being able to redefine almost anything) is lauded as part of Ruby, but when it could theoretically cause any easy-to-avoid problem in JS, it's just more proof that JS is a shitty language.
Sorry if I'm coming across as combative - I don't mean to. I just think this whole snide criticism of JS for every little thing is silly and unhelpful, and has more to do with a superiority complex than actual technical issues.
In Ruby, nil, is a keyword so you can't assign to it nor can you use it as a method parameter.
One of the nice things about JavaScript is that it gives you the ability to accomplish things many different ways, but if someone uses that to shoot themselves in the foot then that is something they need to correct.
That is incorrect. It might be correct if the word 'library' was replaced by 'code snippet' to indicate a copy-and-paste-of-your-code issue. But if you've created a library then your functions are over in some other file, where `typeof undefined === "undefined"`.
The proper attitude here is the same as the Python attitude towards not having `private` attributes: "If some other programmers want to do something crazy with my code, that's their prerogative. If it blows up in their faces, that's their problem."
If `undefined` is an argument name, it's only bound inside that function and nowhere else.
The Crockford quote (characteristically dogmatic, to the effect of 'void means something different in JS than in Java, so AVOID VOID!') is also a kicker.
I guess my any languages are different. Never realized it's importain in haskell (except it is ⊥).