You're wrong

He's right.
There is nothing worse than a mess in development env. PHP itself has introduced a lot of bad practices and now it is very hard to clean it out.

You are referred to devs who have less resources. Do you mean developers who work for free? I'm asking because usually, if environment requires some changes, customer will pay for that. So dev should doesn't care about it.
Other way is to leave old package (php4+mysql4) as is for selected customer. Of course it will require future development based on this old platform. But I understand it is not a problem to you.

Also devs who uses good practices (ie using own db wrapper over native php ones) should have no problem to make it compatible with new versions.

Finally, dropping support for some features is long-term process. So it will not be painful as someones think about.

best regards

I totally agree with artur,
I don't think we should confuse `the real world` with the world of lazy developers and penny less companies, yes there are part of this world but we shouldn't make decisions based only on the requirements of that group. old functionality must be deprecated so new functionality can be added.
Part of owning an internet business is to maintain a website of some kind and that, in some cases, can be very expensive. just as part of a developers job is to update and maintain the code they have created. we can't tell security enthusiasts to ignore security holes because companies and developers don't have the money/time to update their source code. I'm sure those companies are willing to pay their developers to fix new security issues. and I agree with you on the fact that they won't pay them to migrate their code for a new version of PHP. but that is wrong and I think we shouldn't stop because of that.

I do contract work for a guy who has over a hundred sites hosted. He just absolutely refuses to upgrade from mysql4 because of the amount of work it could cause getting all of the sites working again despite the advantages it would give me in writing code for his site. He has upgraded to php 5 at least, which required he get another server and move and test each site which he had to pay someone for (before I started working for him, I've no clue why they didn't upgrade mysql at the time). All this will do is ensure that the next version is slower to be implemented.

The Zend team can't maintain legacy code forever, they dont have enough resources to do so. I had a phone conversation recently with one of the PHP core team devel and he told me about future plans concerning PHP 5.4+ and their inability to implement UTF-8 in aborted PHP 6. The reason? One of the reasons was the fact, that the various extensions used by PHP which had to be rewritten to use UTF-8! A UTF-8! The world encoding standard which is implemented since many years in Python, C#, Java... while in PHP you still need to use exotic extensions like mbstring or Intl.

What's more, as far as I know, the PHP core team is short handed, sometimes there is not enough devs to maintain/improve the existing PHP source code.

You certainly live in a different world from the majority of the developers that develop applications for customers that can only afford shared hosting services.

Rich companies like your customers may not want to spend money on fixing their code, but a) they can afford it, b) they can pay developers that have a clue like yourself that know how to do the things with the least of the problems.

Software that uses the old mysql extension is not buggy just because of that like you claim.

I am not the one to use the old mysql extension. Actually I was the first PHP developer to ever have created a truly portable database abstraction package which allows you to switch databases without rewriting any code in your application.

phpclasses.org/metabase

If developers used Metabase or any other portable database abstraction package (which PDO is not BTW), they would not have any problems with dropping the mysql extension.

It was the main PHP distribution that encouraged to use the mysql until the PHP 4 days. Unfortunately they created new backwards incompatible extensions instead of evolving the mysql extension. That way, most developers that had applications relying on the old mysql extension were not encouraged to use the new extension, because the old one just worked.

Now it is a bit too late to encourage anybody to rewrite millions of lines of code to use newer extensions.

Your TV analogy is perfect to demonstrate what I am talking about. The fact is the color TV system was backwards compatible with the black and white system. It was a single system. Black and white TV would still show color transmissions just fine, only in black and white.

All this to say that the design mistake was of those that created mysqli, instead of evolving mysql to add mysqli features in a backwards compatible way.

But it is probably not too late for MySQL extension developers to just do that, unify mysql and mysqli extension to provide also mysql extension compatible functions, instead of expecting the PHP developers to write wrappers as you suggest.

Finally, I do not agree that the mysql extension is insecure. What is insecure is the code written some PHP developers with lack of knowledge about security.

Not necessarily. You can log PHP errors, so you can see the errors in the log file, without displaying them in pages as you supposed.

When you are in shared hosting, it is not up to you to decide whether the PHP version is upgraded or not. If the hosting company decides to upgrade and your application stops working because of that you will be extremely annoyed.

As for OOP, forcing people to write public, instead of var, does not make the code more object oriented. Only makes PHP code more similar to Java. That is what it was a pointless.

If the mysql extension is to be deprecated, there is nothing for the documentation team to maintain about that extension, because deprecated extensions are not developed, so there will be nothing new to document about that extension.

The matter is that deprecating an extension should not necessarily mean that the extension should be removed from the main PHP distribution. Removing the mysql extension would break millions of sites that are hosted in shared servers on which the hosting companies will decide upgrade due to end of life FUD, like what happened to PHP 5 in 2008.

I thinking you are insulting millions of developers when you call lazy those that do not want to spend time or money updating code to use a different extension that will just provide the same functionality.

PHP 5 added new functionality with MySQLi and PDO extensions. Still it was not necessary to deprecate the mysql extension unlike you claim.

As far as I know, the mysql extension has no security holes. So, that is not a good reason to force developers to switch MySQL extensions, because in the end the functionality of the updated code is the same as before.

Time to move hosts then to one that does support what you want. OFC you can always get a vps, they come as cheap as shared hosting. You can just clone an image of it and keep using that provider for each deployed site, here you can run any configuration you want. LowEndBox is a good cheap vps list, some allowing even more resources than normal shared hosting.

Java was not the first that required explicit access declaration for variable definitions, it's a coding practice that should be followed. Why? Because you can't usually guess where a variable is accesible and PHP's underscore stuff is just ridiculous. Declaring this helps you, anyone reading your code, the interpreter, the ide, the host and anyone else even remotely tied to your source code.

Sorry but these are no arguments to prevent natural lifecycle deprecation and evolution of a language, they are just lazy.