Don't Panic

The first two words of that post are "don't panic" yet you are panicking... ;)

This is not an easy decision, and I won't repeat points made in the proposal but everyone understands that good 'ol ext/mysql is a popular extension, so it's being handled in a gentle yet necessary manner.

Imagine a day when readers of old books/code will visit a manual page that explains better alternatives. I look forward to this day, and look forward to being a part of making that happen. Education is good.

I would not call it panic, but rather serious concern.

The problem is not just marking it deprecated in the documentation. The problematic phrase of your message is the one that says:

"Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0"

Maybe this is not what you meant, but for me it reads:

"It will not be deprecated in PHP 5.4, but it will be in PHP 5.5 or 6.0."

And we all know what comes after deprecation, its death.


Anyway, I have a different proposal that I am sure will bring peace of mind to the PHP community. Actually several other people thought of something similar.

How about merging mysql and mysqli extensions, so it provides both mysql and mysqli function, being the mysql functions internal wrappers of mysqli code?

You could still mark the documentation of mysql functions as deprecated, but they will still work in a backwards compatible way.

While change is good, you DO have to consider the time and profit-loss involved for website developers. They all are now getting forced to change perhaps hundreds of sites each to get it to work with another way of doing there stuff.

Why do I mention profit-loss? Because they cannot charge the customer for the changes. Since the customer already paid for the working product!

And while they do/plan this they probably have one thing on their mind: Which support will remain throughout php's development so they don't need to do it all over again in the (near) future because you guys decide to make yet another extension obsolete/deprecated?

This won't be a problem for all those who used ready made public available systems like joomla/phpBB/drupal and the likes. But think about all those who had to create custom coded stuff just because their customer wasn't satisfied with the available stuff or needed to have something that really had to be custom coded.

Also hosting companies have to inform all their clients about the eventual risks involved before they even consider upgrading their platforms as it will result in many of their sites generating warnings. And in case of this extension I think you can talk about like 70% of all the mysql/php powered sites of this planet.

So yes, web developers DO panic.

I like your merge proposal, Manuel.
That makes a lot of sense.

The proposal does not propose adding errors or removing the extension, nor does it address how we'd handle that. Rather, it's about education and convincing people to stop using the ext/mysql API and instead use preferred/supported extensions which ultimately means writing better code. This is not a new concept. People have been preaching against ext/mysql usage for years, and now php.net will join in on the fun. And I hope you guys read the proposal/thread and not only this assumption-based blog post. Please, go read that thread and conclusion.