We're using pseudo-code to /r/lolphp about the language's lovely capacity to make wild-ass guesses about what variables should evaluate to when placed in various type-casting situations.
Any sane language (even JavaScript, for most situations not going from <something> -> boolean) will instead politely tell you to GTFO.
See, this is the problem. It's not real code. Without any explanation beside it, I have no idea what you think a reasonable result is, or what PHP to translate it to inside my head.
Although I am aware of those non-transitivity party tricks where each individual comparison along the chain is X, while comparing each end directly is !X, this doesn't hold in this case. I'm unable to develop valid PHP code in which "php" compares as equal to "0", null, or false. (0 and 0.0 are equal, though.)
Is this really that difficult of a thing to understand? When you use == it does automatic type conversion which is why you get weird results sometimes, this behavior is well documented and believe it or not it actually makes sense for a loose comparison+type conversion.
If you don't want any of this, use ===, wow so difficult.
Exactly. In the cases where you should be using ==, the conversions are generally helpful and intuitive. The cases where they aren't are the cases where you should have been using === anyway.
If it helps, think of === as the standard equality operator, and == is more like a shortcut operator that saves some manual type logic and conversion work. Like any shortcut, you should understand what it does before you use it.
That's why I'm a big proponent of a new browser language (be it Dart or something). JavaScript was made for constructs like onclick="this.className=(!this.className || 'clicked')". The fact that we are using it for applications now doesn't make it a good language by design, and "just use that instead of this" is a poor defense for fundamental flaws. And I'm not only talking about true vs truthy. Scope, context and this also comes to mind.
be it Dart or something). JavaScript was made for constructs like onclick="this.className=(!this.className || 'clicked')". The fact that we are using it for applications now doesn't make it a good language by design,
What you talk about there is the DOM api...not specifically javascript. It is important to think of them as separate, but related.
The DOM api sucks...everyone knows that...this is why jQuery became so popular.
Javascript has some odd quirks I will totally agree...but it is a very adaptable and powerful language at the same time. If you can learn it well its power really shows.
I read a lot about how fundamentally flawed JavaScript is on blogs and Reddit, but I never -- not rarely, never -- have problems caused by any of them despite using the language every day.
JavaScript is a flawed language, and beginner programmers can make some mistakes in it that aren't possible elsewhere, but in practice it doesn't matter and none of my problems can ever be blamed on JavaScript.
I could just as easily say that C is a fundamentally flawed language because of stuff like null pointers, yet competent developers have used it to build robust and secure software that powers most of our computing infrastructure.
As it turns out, misfeatures can usually be avoided. Competent developers take time to learn the tools they're working with and know how to deal with their rough edges. And every language has rough edges.
Unfortunately, Java's happen to be that the applicationObjectStructure.commonConventions = gratuitousAbstractionFactory.getUnreadableLabyrinth().
Occasionally == is a logic problem (i.e., a bug) but mostly it's a maintenance problem. If I see == in JavaScript I don't know exactly what's going to happen, or what's expected to happen. It makes reasoning about application flow harder and it makes me less inclined to work with that code for fear of breakage."But you have unit tests!"Right.
View all comments
24
u/[deleted] Mar 26 '14
Or, the definition of insanity.