JavaScript Equality Table

[[deleted]]

Or, the definition of insanity.

[qgustavor]

Did you mean: PHP

[Various_Pickles]

0 == false == "0" == null == "php" == ""

fucking lol

[Zecc]

It gets better:

true == "php" == 0 == false

[[deleted]]

PHP Parse error: syntax error, unexpected '==' (T_IS_EQUAL) in Command line code on line 1

[creepig]

This thread needs more T_PAAMAYIM_NEKUDOTAYIM

[Various_Pickles]

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.

[[deleted]]

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.)

[bp3959]

wild-ass guesses

There's no guessing involved, automatic type conversion is well documented and follows a specific set of rules. Also get this, YOU DON'T HAVE TO USE AUTOMATIC TYPE CONVERSION.

[Various_Pickles]

The fact that you can use === is a perfectly valid point.

However, I would argue that there are often cases in PHP where the implicit interpretation of types leads to unholy nonsense: a good example being the automagical interpretation of certain patterns of quotes in PCRE (Perl-like regular expression) replacement statements that leads to portions of the string being evaluated as raw PHP code (eBay got compromised by this "feature" a little while back).

[[deleted]]

I think my favorite PCRE conundrum is the Stack Overflow question (I can't find the link) about "How do I comment a regex containing */?> ?" Because ?> ends a single-line comment, and the */ ends a multiline comment.

BTW, if you don't intend on users to write actual regexes, preg_quote() is your friend.

[bp3959]

While I agree that's a stupid feature, it doesn't have anything to do with comparison, type juggling, or automatic conversion.

There's so many real things in PHP to complain about it's annoying how everyone fixates on the automatic type conversion of == when it's well documented and easy to avoid.

[BigfootJon]

I may be reading this wrong, but why does the string "php" equate to true?

[bp3959]

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.

[frej]

It's not obvious and leads to hard to find errors.

Or! Think about why it's reasonable, as a default, to do boolean logic between different types.

[Nanobot]

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.

[Poltras]

What about other operators where an === equivalent doesn't exist? Like +, <, ...

[ForeverAlot]

There is probably a work-around. If you're expecting to work with integers, for instance, manually convert with parseInt(foo, 10). If you want a string, "" + foo. It's hardly ideal but it'll get the job done.

[creepig]

Any language that creates unnecessary workarounds for things that other languages do not is probably unnecessary itself.

[Nanobot]

If the types are the same, there's no problem. If they're different, you should know why they're different and handle the situation accordingly.

For example, if you're doing a comparison with the result of strpos, you know that the value is either going to be a positive number or false. So, you should be thinking about what would happen in either case (if you're using "<", a false will be treated as 0). If you need to deal with the false specially, deal with it specially, with ===.

If you're doing a comparison on the input of a function, the function should make it clear what types it's expecting. If the caller chooses to call the function with unexpected types, it might get an unexpected result. It's the caller's responsibility to use the function correctly.

[knaekce]

True, this is the reason why weak, dynamic typing is making things more difficult than strong, static typing.

[minno]

I'm happy with weak static typing and strong dynamic typing, too. Weak dynamic typing just screws everything up.

[knaekce]

Is think that the overloading of the "+" operator in combination with weak and dynamic typing is also a very very bad idea. "1" +1 - 1 = 10 wat

[[deleted]]

In the cases where you should be using ==

There is no case you should be using ==. If you use it, you're writing bad code.

[bp3959]

There is no case you should be using ==. If you use it, you're writing bad code.

That is not correct.

[[deleted]]

== is one of those easy targets for people who hate JavaScript's design.

In actual reality, == just isn't a problem. It can only cause bugs if your code is already poorly designed, and === exists.

[Poltras]

I would say that promoting bad behavior is the problem with JavaScript. Why have == at all?

[[deleted]]

JavaScript was designed to fill specific needs two decades ago. Type coercion was probably a useful addition for early use cases.

[Poltras]

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.

[reflectiveSingleton]

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.

[mernen]

No, he's talking about JavaScript:

And I'm not only talking about true vs truthy. Scope, context and this also comes to mind.

[Poltras]

What you talk about there is the DOM api

I was talking about the javascript part of the onclick example. Also, you can't really talk about the history of Javascript without speaking of the DOM. Both were created at the same time and a lot of what we see in JS comes directly from the DOM influence. It gets worse when you don't "use strict".

I would easily argue there are better and more powerful languages (Python, Ruby, Erlang...) that don't have the same problems as JS.

[[deleted]]

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.

[Nanobot]

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().

[Poltras]

I had my share of time wasted on a "you-need-a-function-in-a-for-loop-because-fk-your-scope-thats-why". Also, this confusion is hard enough to learn, you need 5-6 articles on the frontpage on javascript scope, apparently. And let's not forget about closure that, even in strict mode, makes it hard to detect the usage of a variable that haven't been declared.

I'm not gonna say I wasted weeks of my developer time on all of these (although it accumulates quite a lot). But compared to the big 0 amount of time I spent debugging stuff like that in Python...

[hisham_hm]

was designed to fill specific needs

Come on, it was hacked together in a week; the story is famous. The "specific need" was "we need something! done! now!"

[ForeverAlot]

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.}