proj-plbook-plChPhpLang

Table of Contents for Programming Languages: a survey

PHP

Because of its popularity, PHP gets its own chapter.

Tours and tutorials

Respected exemplar code

gotchas

" Half the array functions take arrays as the first arg, the other half the last.

explode and implode have different argument order requirements (one is strict, the other works either way).

Functions have a grab-bag of errors from returning null to false to 0 to strings to requiring error\_get\_last to even requiring an object specific error function (DateTime::getLastErrors).

Functions were named to make them have more randomly distributed hashes (http://news.php.net/php.internals/70691). Functions randomly do or don't have underscores, sane order, etc.

Some apis are in terms of objects (DateTime?), some are not (getdate). " [4]

dietrichepp 12 hours ago

I'm not exactly clear on how PHP == works, but you can see the MD5 for yourself:

    $ echo -n 240610708 | md5sum
    0e462097431906509019562988736854  -
    $ echo -n QNKCDZO | md5sum
    0e830400451993494058024219903391  -
    $ echo -n aabg7XSs | md5sum
    0e087386482136013740957780965295  -

All of them start with 0e, which makes me think that they're being parsed as floats and getting converted to 0.0. This is why "magic" operators like == in PHP and JavaScript? never should have existed in the first place. Operators like == should be, by default, extremely boring. PHP's just happens to be a bit more magical even than JavaScript?'s.

reply

DoubleMalt? 10 hours ago

Once I wrote a little PHP application to manage a clan in a browser game. I used an MD5 hash as session id that I checked with if(session_id)

When users started reporting that their logins would sometimes not work at the first time, I found out that strings that start with zero are coerced to 0 and then interpreted as false.

Never used PHP for anything important since.

reply

ams6110 7 hours ago

To be fair, this kind of thing (maybe not exactly this, but type-coercion bugs) can happen in JavaScript?, which is all the rage now for "important" stuff.

reply

shuzchen 25 minutes ago

This is levels worse than what Javascript does though. Most high-level languages have some sort of implicit coercion (even python lets you do truth tests on non-boolean values). The problem here is the programmer isn't confused about types at all. They're comparing two things of the same type: two strings! Nevertheless, given two strings PHP tries to coerce them into ints before carrying out the equality test. Yes, you will have coercion bugs in other languages if you're testing things of different types, but I don't know any other language where a equality test between two things of the same type are automatically coerced into another.

reply

lars 12 hours ago

This, combined with the fact that you can increment strings gives some 'interesting' results:

    $a = "2d9"; 
    $a++; 
    echo $a . "\n"; 
    $a++; 
    echo $a . "\n"; 

Output

    2e0
    3

kyllo 7 hours ago

Ahh PHP, the language where true == false

    php > if ((true == "foo") && ("foo" == 0) && (0 == false)) echo "yay!";
    yay!

reply

shubhamjain 12 hours ago

PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Strings type-casted to integers are 0. Seriously? Take a look at this,

> $arr = array(0, "was", "invented", "in", "india");

> var_dump( in_array("Hello", $arr ) );

and yeah it is TRUE because "Hello" got coerced to 0. I blogged about a major bug, I faced, in PHP, where column name "10th_grade" was being type-casted to "10" failing the "bindParam" [1]. Even if they have to continue this "feature" because of backwards compatibility, the least they could have done was NOT to use it in the newer functions but no, even they have this stupid "type juggling".

[1]: http://coffeecoder.net/blog/my-perfect-reason-avoid-php-type...

reply

tragomaskhalos 9 hours ago

There are a couple of things we have learnt in our collective 50+ years of software engineering:

1. Code is not English: Nice try COBOL, and someone had to try, but a failed experiment. Bizarre holdouts: SQL

2. People are not idiots, and will not collapse into a gibbering heap if their programming language insists that 0 and "0" are different things and must be managed accordingly. Bizarre holdouts: PHP, Javascript. Honourable mention: Excel (no Excel, that is not a f&@cking date, I will tell you if I want a date).

reply

WalterGR? 11 hours ago

    PHP's type coercion is nothing like I have
    every seen in any other language. Its
    horrendously messy, ugly and completely
    inexcusable. 

Is it objectively worse than type coercion in JavaScript??

reply

oisyn 7 hours ago

Oh yes. In Javascript, the operands are only coerced if one of the operands is a number. So when comparing two strings (regardless of whether the strings can be interpreted as a number), you always get a regular string compare.

  "12" == "12.0" -> false, basic string compare

Furthermore, if one operand happens to be a number, and the other operand has illegal characters to be interpreted as a number, the two operands aren't equal.

  0 == "foo" -> false, "foo" is not a valid number
  12 == "12 monkeys" -> false, "12 monkeys" is not a valid number
  12 == "12.0" -> true, "12.0" is a valid number, and compares equal to 12.

In short, in Javascript the == operator actually makes sense. In PHP, every single one of above examples would evaluate to true.

reply

romaniv 6 hours ago

While it is obvious that PHP's == operator is horrible, JavaScript? has its share of pretty bad issues, like "x" - 1 giving NaN?.

What I don't understand is why some people agree that PHP is a horrible language, while at the same time praising JavaScript? as messiah of scripting. These two languages don't just have problems, they have very similar problems. Moreover, they gained popularity for very similar reasons (lack of choice).

Seriously, if you posted something similar to OP about JavaScript? the first thing people would tell you is "What, you're still not using ===?!"

reply

"PHP makers made their share of mistakes with their decisions - register_globals, safe_mode (which was not), inconsistent function naming in standard libs, myriad of weird bugs (like syntax error (still) throwing HTTP response 200)" -- https://news.ycombinator.com/item?id=10797375

ams6110 15 hours ago

Is it any worse than Javascript, if we're honest?

reply

pdpi 15 hours ago

Yes it is, and I really don't like JS much to begin with.

There's seriously wonky things in there like the associativity on ?: being wrong, and == being even more broken than in js. There's order of arguments on array_map and array_filter being inconsistent. It's not that there's a massive flaw in there that kills it, it's death by a thousand paper cuts.

reply

mywittyname 14 hours ago

PHP's massive flaw is that it does one thing very well (web-dev), but does everything else rather poorly. It becomes the default choice for projects that start out as a web front-end, but then gets used in other situations where it's ill-suited. A lot of PHP projects have components that are hacked together and work, but are confusing and less-than-ideal from a design perspective.

Threading/asynchronicity comes to mind. I've worked on a few projects that started out as a web-front end, but then needed to do some background processing. Eventually the background process needs to be multi-threaded and the choices are: rewrite your code to support pthread's wrappers classes, use fork and shared memory segments, asynchronous web requests. All those solutions work, but they are much more complicated than the same task would be in most other languages with native threading support.

reply