Re-visiting »PHP: a fractal of bad design« in 2020

Wednesday, 2020-09-16 17:00

Re-visiting »PHP: a fractal of bad design« in 2020

I love PHP. And I love Eevee's (a.k.a. Evelyn Woods) blog post about PHP's bad design from 2012. Mostly because it's so massive. It lists really everything anybody ever disliked about the language, and explains why. It's fun to read. And it's true. Or at least was true. The post was compiled in 2012. The most recent – and only supported – version we had back then was PHP 5.3, as well as 12 painful years with PHP 4. And yes, PHP 4 was still in use pretty much everywhere. Adoption was notably slower back then.

It's 2020, and PHP 8 will be released in less than 3 months, according to the plan. And oh boy, what a leap forward! The PHP 8 changelog reads like they are finally fixing some of the worst design mistakes in the language.

Time to re-visit the »PHP: a fractal of bad design«.

2020-09-16 19:17: good post

only I beg to differ on some points

like that thing about return values - those are actually far worse than in typesafe languages; DAT
2020-09-17 04:32: Which return values? Returning false in case of an error is a very common thing in PHP. MediaWiki does it as well in places. I don't say I like it. I prefer null or Status objects that tell you if an operation was successful. The thing with -1 is: it's a special case, just as false. Neither does make the code easier to read.

The worst thing might be that we have to use strpos() !== false way to often because we didn't had str_contains() before PHP 8.; Thiemo
2020-12-01 14:41: > "Negative indexing […] Wasn't this blog post about consistency?"

It exists in many languages and it's perfectly consistant

> "This one datatype acts as a list, ordered hash, ordered set, sparse list […]"

The main problem is that there is not details about implementation and no alternative. As the original author mentionned it, it's not about "liking it or not", it's about efficiency and tooling.
A vector is not a Set and is not a Hash. They have different purposes and different specs, leading to better (or worse) performances / capabilities according to the given situation

> "array_search, strpos, and similar functions return […] false […] Yea, and other languages return -1. Is this really better? […] Sure, there is a difference: It's much more likely for a -1 to produce a runtime error, and much more likely for PHP's false to not do this."

Your answer is bad faith. The problem being 0/false vs 0/-1 is that false is true when compared to 0. So if(strpos == 0) will return true whether the needle was at pos 0 or not in the haystack. You're partially quoting the original point to not answer it.; TMLPESSLBDP
2020-12-02 16:16: > "The main problem is that there is not details about implementation and no alternative."

This is not true, see php.net/manual/en/book.ds.php.

Additionally, you have interfaces like ArrayAccess which allow you to implement any "array like" class you need.; anonym
2020-12-09 13:04: I even said "sure, it's much more likely for false to [silently become 0]". So much for partial quotes. But the complaint about returning false is really just repeating the complaint about the == operator. My argument stands: returning -1 is just as much as a hack as returning false.

Besides, I just realized when we make strpos() return -1 and allow negative indexing the same time, we created just another trap to fall into.; Thiemo

Kommentare zu diesem Beitrag können per E-Mail an den Autor gesandt werden.

Thiemos Archiv

Re-visiting »PHP: a fractal of bad design« in 2020