Javascript | Php |
---|
| |
if ( 2 ) | if ( 2 ) |
if ( -1 ) | if ( -1 ) |
if ( false == 0 ) | if ( false == 0 ) |
if ( false == '0' ) | if ( false == '0' ) |
if ( false == '00' ) | |
if ( false == '0x0' ) | |
- we see that JavaScript parsit the string with the number more carefully. We go further |
if ( 'bla bla bla' ) | if ( 'bla bla bla' ) |
| if ( false == null ) |
- amazingly, but in JavaScript, false is not null |
if ( false == !!null ) | if ( false == !!null ) |
- but if we double negative null - javascript behaves like PHP |
| if ( false == $undefined ) |
- oops! undefined is also not false in javascript |
if ( false == !!undefined ) | if ( false == !!$undefined ) |
- double denial again changes things |
| |
if ( true == 1 ) | if ( true == 1 ) |
| if ( true == 11 ) |
- Another feature - in PHP, any non-zero number is true. In JS, only one |
if ( 11 ) | if ( 11 ) |
- but if we transfer the number directly to the if - then in both languages everything is true that is olchical from zero |
| |
if ( '0' ) | |
- perhaps the most insidious distinction of JavaScript and PHP. Farther |
| if ( true == 'true' ) |
- also an important difference - PHP leads the string to boolean, and JS causes the boo to string |
| if ( true == -1 ) |
- again, the difference - in JS true is reduced to a number (it turns out 1) and compared with -1. And in PHP -1 is returned to boolean (it turns out true) |
if ( 'bla bla bla' ) | if ( 'bla bla bla' ) |
| |
if ( undefined == null ) | if ( $undefined == null ) |
| |
if ( 1 == '1' ) | if ( 1 == '1' ) |
if ( 2 == '2' ) | if ( 2 == '2' ) |
if ( 2 == '02' ) | if ( 2 == '02' ) |
if ( 2 == '0x2' ) | if ( 2 == '0x2' ) |
| |
| if ( '-1' == true ) |
| |
| |
- in JS there is even a variable that is not equal to itself! This is NaN |
Have you ever written the terms in javascript with full confidence?
Some, naively believe that their uncertainty in the conditions of JavaScript is associated with an insufficient knowledge of the language. In fact, the root of evil in Java Script itself. It is specially designed to break your brain. And this is how he does it:
You as a thinking person believe that the == operator makes a comparison with type conversion. We also intuitively feel that zero, null, false, and the empty string are something zero. And when casting to a boolean value should give false values. Also, you probably think that the == operator, if one of the Boolean type arguments first leads the second value to a boolean type, and then compares it? Ha-ha-ha, and here and no, the creators of JavaScript are now viciously rubbing their palms in anticipation of the destruction of your brain cells.
')
No, JavaScript of course leads the type when comparing with the == operator, but it does the opposite of what you and I expect. Especially those of us who wrote in PHP.
Here is an excerpt from the operator’s documentation ==:
If two operands are not of the same type, javascript converts the types and compares strictly. If either operand is a number or a boolean value, then the operands are converted to numbers; if any operand is a string, the second is converted to a string
But here is an example:
if( null == false )
One of the operands is a boolean type. According to the documentation, both operands must be converted to a number. Number (null) 0 and Number (false) will give zero. The condition should be met, but this does not happen. Just the creators decided that null is a special meaning? In my mouth, my feet! No, rather, he thought like this: null is a type of Object. JavaScript false results in the Object type (some kind of stupid array object is obtained with one false value inside), and then it
compares these two objects . Or maybe both of these values
are cast to a string, get 'null' === 'false'? No, actually:
If one of the operands is boolean, then it is converted to 1 (one) if it is true. And to 0 (zero) if it is false.
If an object is compared with a number or a string, javascript tries to get the corresponding value for the object. It converts an object to an elementary value, string, or number using the valueOf and toString methods. If the object cannot be converted, a runtime error is generated.
Anyway, this is not the best solution. We expect operands to be boolean, and they are reduced to something else. PHP is more expected in this case.
Next, we check the string with zero inside for equality:
if('0' == false)
Strange, isn't it? If '0' is false, but if we check it directly in the if condition, then it gives true. It's simple. The creators of JavaScript decided that if we cast the string to a boolean, then the
length of this string would be checked. If the length of the string is greater than zero, this is true. False is obtained only if the string is empty. And in the first case, when we check '0' == false, not the string is cast to Boolean, but on the contrary, false is reduced to zero and compared with the string '0'.
The same with numbers - despite the fact that:
if(true == 2)
Why? Everything is simple - the Java script, when comparing with the operator ==, first
returns true to one (1) , and then compares it to the two (2). Of course they are not equal and the condition will not be fulfilled. As we can see, JavaScript during boolean operations prefers to bring boules to a number, and not vice versa.
But in vain, incidents would be less.
Easy exit
The easiest way out is to put double negation before operands
!! . This will uniquely lead any type to Boolean. But we must remember that !! '0' in the java script will give true, unlike PHP. Because the Java script measures the length of a string when casting to a Boolean, and PHP first calculates the numeric value of the string, and then it brings the Boolean.
Spare the brains of programmers
If you break the head above, then maybe you will not immediately make a complete picture of what happens in JavaScript and why it is different from what happens in PHP. The picture will be ugly because of the undistorted details. The fact is that we like everything logical, we like to understand the system,
all exceptions to the rules are a nuisance. Exceptions undermine understanding, creating a sense of discomfort. Let's do the clear things!
Some writers, plunging into the depths of the program, forget from consumers, about those who will enjoy the result of their work. Forget about what the majority expects to get. Some kind of logical
justification becomes higher than ease of use, which is fundamentally wrong. Spare the user's brain, take a sober new look at what you are creating, think about what you want at this moment and what you expect from the system. To do this, simply listen to yourself. And be sure to ask the opinion of users.
Otherwise it will turn out as in JavaScript.
Thank you for your attention, I wish that your life was more understandable, Oleg Jozhik.
PS
See a more visual comparison table
here.Modest advertising: I recommend using
MicroMail to send files