Back in the day, the way it integrated with Apache was an evolutionary advantage to PHP. It found a strategy that worked in its environment and it thrived. That environment no longer exists, but PHP holds on vestigially.

We didn't have AWS or other cheap, virtualized hosting way back when. It was all shared plans where you had a directory of your stuff, and it was there with a hundred other people on the same server and Apache instance. You could run whatever you wanted as a CGI, but that was even worse; it forks off a whole interpreter for the language, parses the code, and then used STDIN/STDOUT to communicate. Even if you implemented it in compiled C code (which had all the other problems you would expect), that fork is still expensive.

Projects like mod_perl and mod_python built an interpreter directly into Apache, but there was a problem with how it worked: it was too sophisticated. They could hook into the entire Apache API. That meant that there was no way to separate your stuff from every other thing on the same shared hosting plan. Any one instance would be able to fool around in all other accounts. That's untenable, so your choices for those languages were to either get a dedicated plan at well over $100/month, or stick with a $5/month shared plan and put up with it being unscalable.

Enter mod_php. It builds the interpreter into Apache, but that's all it does. Still have a parsing step, but it doesn't have to fork. Doesn't try do anything else. Its fast, and it can be hosted on cheap shared plans.

If you're a startup at this time, operating on frozen pizza and office chairs from a thrift store, then you could get a cheap plan, develop it under CGI, and hope that you can refactor it later when you can afford a dedicated plan. Oh, and keep in mind that CGI doesn't lend itself to converting easily to the Apache API or whatever else you're going to use in the future. Alternatively, you could build it in PHP and it will be fast now and acceptable later.

It's no great mystery why PHP was chosen at the time. There were limited options, and it was the cheap, get it done now option.

Simply because it was an issue that I ran into at work. And the reason I focus on arrays is because of the previously mentioned default behaviour of arrays being cloned when passed as an argument for a function. The issue here was someone unexperienced wrote a bunch of code and used only arrays (deep ugly arrays) and it ended up being a huge mess of some references staying the same while others changed. So the only solution was to deep copy at one place. That way later operations on these arrays didn't affect the original structure. Not pretty but refactoring would have been too much effort.

Can't open the one response you got. So maybe someone already answered. But this here

https://www.php.net/manual/en/book.ds.php

Right alt + 4 for me lol

Sorry for being lazy so no sources for now. But based on my research back then. Using clone (on arrays) is actually slower then json_encode/json_decode.

So there are some cool optimization tricks going on in the background. But that doesn't make it any more intuitive for me.

Arrays are passed by copy by default. Every scalar or array value is copied by value. Every other thing (objects basically) is copied by reference.

Passing array by reference passes everything it used to copy by reference.

Attempting to clone an array will result in an error.

Reassignment of a variable containing an array will do the same as if passed to a function by value.

Reassignment of a variable containing an array using the reference operator will do the same as if passed to a function by reference.

So, in order to deep copy an array, just reassign and recursively traverse the array calling clone on each object. Of course, this would break (or not, depending on the intended use) when the same object is referenced multiple times under different keys.