PHP WTF: A PHP Annoyance Posted Every Day(phpwtf.org)
phpwtf.org
PHP WTF: A PHP Annoyance Posted Every Day
http://www.phpwtf.org/
12 comments
People who make heavy use of a language are in a good position to vent about its shortcomings. Sometimes a language is the best tool for the job despite its many deficiencies, and I'd much rather read these kind of rants by someone who knows the language inside out. I hate PHP more than I hate my own mother, and yet I still chose it for my most recent project. Every programming language has shortcomings, it's just a question of picking the best shortcomings for the job.
Yeah, he even has some sort of disclaimer in his footer
This site is mostly written by chx, one of the core developers of the PHP-based Drupal project. It's not meant to be a bashing of PHP or its authors.I hate PHP more than I hate my own mother
I've heard of damning with faint praise, but this is more like faint condemnation...
I've heard of damning with faint praise, but this is more like faint condemnation...
[deleted]
By using PHP, he'll never run out of material. :)
You can move to a new language whenever you want. But will your community follow you? Not without a great deal of groundwork.
If you want the strict non-coerced equality, I think you are supposed to use === as in javascript.
So:
0 == 'x'
bool(true)
daeken explained it quite well. From his post:
"As explained under 'read more', it's because 'test' will be cast to a number for comparison. Since 'test' isn't a number, it becomes 0, which is equivalent."
"As explained under 'read more', it's because 'test' will be cast to a number for comparison. Since 'test' isn't a number, it becomes 0, which is equivalent."
These tables illustrate how complicated type checking in PHP really is: http://www.php.net/manual/en/types.comparisons.php
if ($countarticles == '2') { postponeLaunch($credibility); }
No need for the '' around 2 ;)
It's PHP, it works anyway.
[deleted]
If they ever make it to posting #3, there is a chance this site will outlive php.
You need a submission form. or not... there's no way you could sort through all the submissions you'd get.
If you can keep it from devolving into thedailywtf.com then you'll have a very loyal reader in me. I work in PHP and I would love to hear a list of valid frustrations instead of the general PHP bashing.
If you can keep it from devolving into thedailywtf.com then you'll have a very loyal reader in me. I work in PHP and I would love to hear a list of valid frustrations instead of the general PHP bashing.
Did anyone read this disclaimer at the bottom of the page?
"It's not meant to be a bashing of PHP or its authors."
And if so, does anyone understand how that site isn't mean to be a bashing of PHP? I mean, he's free to bash it if he wants, but does that even make sense?
"It's not meant to be a bashing of PHP or its authors."
And if so, does anyone understand how that site isn't mean to be a bashing of PHP? I mean, he's free to bash it if he wants, but does that even make sense?
Yes. While it seems to be the trend to bash on PHP there's nothing wrong with discussing it's shortcomings in a constructive manner.
please someone create aspwtf
While we're doing outdated technologies, can we also do a COBOL wtf?
OK, I'm stumped, why is this?
echo "<?php if (0 == 'test') echo 'true???'; ?>" | php # => "true???"As explained under 'read more', it's because 'test' will be cast to a number for comparison. Since 'test' isn't a number, it becomes 0, which is equivalent.
Which is, of course, a deeply broken way to handle the situation. If multi-type comparisons have to be supported at all, at least one ought to cast the narrower type to the wider one! In this case, the int argument ought to be cast to string, because all ints can be uniquely represented as a string, but not the other way around.
As it stands, PHP's equality operator is not an equivalence relation because it's not transitive. This is deeply unintuitive and logic-defying.
As it stands, PHP's equality operator is not an equivalence relation because it's not transitive. This is deeply unintuitive and logic-defying.
== is not the equality operator. === is the equality operator.
== is the type coerce/cast and then compare operator.
I agree with you about the way strings get converted to int instead of the other way around. I believe this is a backwards compatibility issue, and if they could change it they would, but it's too late.
It's also because of 1 == "01" would be false otherwise. And if you think "01" is strange you forget that all input to a php program comes from web forms, and is always a string.
== is the type coerce/cast and then compare operator.
I agree with you about the way strings get converted to int instead of the other way around. I believe this is a backwards compatibility issue, and if they could change it they would, but it's too late.
It's also because of 1 == "01" would be false otherwise. And if you think "01" is strange you forget that all input to a php program comes from web forms, and is always a string.
in javascript:
1 == '01' --> true
0 == 'x' --> false
1 == '1' --> true
true == 'asdf' --> false
'-2' == 2 --> true
'-2' == 0 --> false
Seems like in javascript, the coercing is much more sane. In php, all of the above statements would end up true.
1 == '01' --> true
0 == 'x' --> false
1 == '1' --> true
true == 'asdf' --> false
'-2' == 2 --> true
'-2' == 0 --> false
Seems like in javascript, the coercing is much more sane. In php, all of the above statements would end up true.
Javascript is not totally sane:
PHP is much more strict about the rules used when doing the comparison, javascript is more loose. It tries to guess.
When comparing a string to a number, if the string looks like a number it's converted to one. But if it doesn't, then instead the number get converted to a string.
This works well most of the time - but not always, since it can surprise you. PHP is more strict, so it doesn't work as often, but it fails more consistently, so it's easier to find the problem.
Another example:
'\t\r\n' == 0 --> true
"false" == "0" --> false
"0" == 0 --> true
0 == false --> true
false == "false" --> false
PHP is much more strict about the rules used when doing the comparison, javascript is more loose. It tries to guess.
When comparing a string to a number, if the string looks like a number it's converted to one. But if it doesn't, then instead the number get converted to a string.
This works well most of the time - but not always, since it can surprise you. PHP is more strict, so it doesn't work as often, but it fails more consistently, so it's easier to find the problem.
Another example:
"1" == "01" --> false
"01" == 1 --> true
1 == "1" --> trueThe funny thing is that in Javascript:
12 == parseInt('012')
returns false. :)
12 == parseInt('012')
returns false. :)
A leading zero usually means 'this number is octal', so parseInt returns 10. Not very intuitive notation, however.
I don't have a PHP runtime in front of me, but IIRC the first one on your list and the last 2 will evaluate false in php
I really would find this "deeply unintuitive" if I decided to try PHP with only intellisense as a reference. But by their very definition a language's idioms are not obvious. And this isn't my first rodeo, so I'd know that. And I'd read a little--just a little--before i jumped in.
Concepts and algorithms are universal. Operators and keywords are not.
Luckily, this is such a common need when learning a language that this information is kept all together in a tidy tabular way.
Because without it, I'd probably whip up an index.php and write something like print 'Welcome, ' + user.firstName;, get frustrated by parse errors, then by runtime errors, then write some impassioned comment about how deeply unintuitive it is to require prefixed variables and how using a dot for concatenation instead of a plus sign or ampersand is simply logic defying.
And that same table that explains concatenation and scope resolution is also going to give me a simple treatment on the == and === operators in this weakly typed language.
PHP is not an elegant language and given the choice, I'd nearly always prefer to be writing something else. But I took my time to respond to this because there's enough wrong with PHP that we don't need to resort to hyperbole to bash it.
Concepts and algorithms are universal. Operators and keywords are not.
Luckily, this is such a common need when learning a language that this information is kept all together in a tidy tabular way.
Because without it, I'd probably whip up an index.php and write something like print 'Welcome, ' + user.firstName;, get frustrated by parse errors, then by runtime errors, then write some impassioned comment about how deeply unintuitive it is to require prefixed variables and how using a dot for concatenation instead of a plus sign or ampersand is simply logic defying.
And that same table that explains concatenation and scope resolution is also going to give me a simple treatment on the == and === operators in this weakly typed language.
PHP is not an elegant language and given the choice, I'd nearly always prefer to be writing something else. But I took my time to respond to this because there's enough wrong with PHP that we don't need to resort to hyperbole to bash it.
I mostly agree, except that I don't think any treatment explaining
NULL != "0" == false == NULL == 0 == "false" == true
Sure it is:
To avoid implicit type coercion, use the identity operators === and !==.
Of course, the code you posted doesn't parse without adding parens. And when you do, it becomes much more obvious what it's doing and why.
To avoid implicit type coercion, use the identity operators === and !==.
Of course, the code you posted doesn't parse without adding parens. And when you do, it becomes much more obvious what it's doing and why.
Sorry, I meant that as a bunch of compares that are mutually inconsistent, not one big expression. And "don't use ==" isn't really a solution until you persuade the runtime and every major library author to stop using it.
I don't get your point. Nobody has said "don't use equality." Equality is the right choice nearly all the time.
I've worked on some very large web apps (mostly C#, Python and PHP) and I can't recall ever really being foiled by php's implicit casting.
Just out of genuine curiousity, can you share an example where this caused a problem that you had to debug?
And if php implicit casting did somehow cause you problems, surely it was fixed by changing it from equality to identity?
So in summary... this could potentially cause a bug, but probably not, and if it does, it would be a consistent bug, and it would be fixed by a single keystroke.
Why, again, are we talking about this?
I've worked on some very large web apps (mostly C#, Python and PHP) and I can't recall ever really being foiled by php's implicit casting.
Just out of genuine curiousity, can you share an example where this caused a problem that you had to debug?
And if php implicit casting did somehow cause you problems, surely it was fixed by changing it from equality to identity?
So in summary... this could potentially cause a bug, but probably not, and if it does, it would be a consistent bug, and it would be fixed by a single keystroke.
Why, again, are we talking about this?
That isn't legal PHP.
[deleted]
Unlike many blogs, at least this one will easily have enough material to keep going for several years.. ;-)
PHP has many problems. We know this. There are millions of words online that will attest to this fact. The fact is, all these words are for naught if people don't step in and do something about it.