Not really

But it does cost to maintain. There may be function calls and restructuring in the PHP Core that require the team to make changes to the C code that is the mysql extension. For all we know PHP could be implementing a new StackManagement system in the VM that causes most extensions to be modified. Or possibly switching to using Boost/SmartPointer's. Changes like that will cause a lot of changes in large libraries. Which means that for the PHP Core (VM) to progress they will need to EOL cycle code that has better alternatives.

I agree with the PHP team on this. If there is a better solution that fits the language more, use it.

I am glad that they are deprecating the mysql lib before just removing it. It allows developers to catch the errors before the site stops working.

I personally have not used mysql lib for at least a year now. I like and use the PDO extension.

Philip's changes specifically say that his proposal is only about documentation. This is his area of specialty. His post said "This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now." He goes on to say "This proposal only deals with education, and requests permission to officially convince people to stop using this old extension."

So he is very clearly deferring any code change decision. No one in the PHP community is planning at this stage that any code changes will be made. There hasn't been any discussion. There is no one starting that discussion. It is an open question and nothing has changed from before his post.

Philip doesn't even mention removing the "mysql" documentation. And it's not a matter of whether maintaining that documentation is difficult. In fact, it's not difficult to maintain the status quo for a stable extension. It's a matter of what message the PHP core community sends to users about best practices. Philip even proposes creating more documentation to help disambiguate that message.

Finally, discussion of Zend in this thread is odd. They contribute to PHP like many other people but to mention "cost" in relationship to maintenance indicates a misunderstanding of their role.

Philip's changes specifically say that his proposal is only about documentation. This is his area of specialty. His post said "This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now." He goes on to say "This proposal only deals with education, and requests permission to officially convince people to stop using this old extension."

So he is very clearly deferring any code change decision. No one in the PHP community is planning at this stage that any code changes will be made. There hasn't been any discussion. There is no one starting that discussion. It is an open question and nothing has changed from before his post.

Philip doesn't even mention removing the "mysql" documentation. And it's not a matter of whether maintaining that documentation is difficult. In fact, it's not difficult to maintain the status quo for a stable extension. It's a matter of what message the PHP core community sends to users about best practices. Philip even proposes creating more documentation to help disambiguate that message.

Finally, discussion of Zend in this thread is odd. They contribute to PHP like many other people but to mention "cost" in relationship to maintenance indicates a misunderstanding of their role.

mail: christopher.jones@oracle.com
twitter: @ghrd

Agreed with Arthur, Donald Duvall and others. The point of encouraging better coding practices is to eliminate maintenance headaches. The outraged squeals of those who don't want to maintain their legacy mysql_ code prove the point. Proper software design avoids these problems. Killing the legacy library is a case of being cruel in order to be kind.

Note, too, that the desirable practice of putting SQL operations into internal functions or procedures gives huge performance gains, but is impossible with the legacy library.

As to "unsightly" E_DEPRECATED notifications: well, if one is happy to go on using deprecated features, one will simply turn these off!

My guess that a documentation team member is proposing to deprecate an extension, so they can save time maintaining its documentation, is just that, a guess.

They did not make clear any other motivation for this proposal, so we can only guess. There is no reason for anybody making guesses when the motivation for an initiative was not presented explicitly. Maybe it is just a problem of communication.

Deprecation is just one step before discontinuation. If they are not going to discontinue it in future revisions, why it is so important to urge PHP developers to drop mysql extension in favor of MySQLi of PDO?

Now it is curious you are calling me arrogant and blind, while it seems to be you the one that is missing the point by ignoring the thousands, if not millions of sites and developers that will be upset by these decisions.

PHP ships with tens of extensions. An eventual change in the interface with the extensions, it is not removing one very popular extension that will save so much time and effort to PHP core developers.

On the other hand, removing that popular extension will cause major headaches to thousands (if not millions) of developers and site owners. That will only make them avoid to upgrade for as long as they can to the PHP version that drops that popular extension.

That is why PHP 5 adoption was a fiasco. Many developers only upgraded when they were forced to upgrade because they had no better alternative.

What happens with many developers when they try using a newer version and it throws too many warnings that did not appear in past versions, they simply refuse to upgrade without even trying to understand what the notices mean.

That is why the the var warnings of PHP 5 scared many developers from upgrading to PHP 5. They could have suppressed the warnings, if they had a clue. But many developers did not have any clue to even try understanding what the warnings meant.

You may wonder, but those are not smart developers, and you are probably right. But the reality of the PHP world is that there are really many, many developers that are not that smart. Some are not even programmers.

Some are just Web designers that got orders from customers to build sites for them. So they learned PHP because it was the easiest path for them to do all the work and collect all the customer money, instead of hiring the development work to a real programmer.

You may wish that all PHP developers would be more knowledgeable, but that is the reality of the PHP world. Part of the reason of why PHP is so popular is that unlike other languages, PHP is easy for this type of developers, which probably never programmed before.

Dear Manuel, With all due respect, I disagree. It seems you have an emotional issue with web developers that work for less than programmers wages, but that happens in your own world. Please reconsider if you are capable of telling "us" what the "PHP world" is all about and what the objective reality and truth of the world would be. Even if you really know, please leave me the surprise.

As long as I write code in PHP (for my customers too, I am not a programmer, but in Germany that is legal) my webhoster and all other people I know give me freedom of choice which PHP Version to use. I have no reason to believe that this would change in my personal world, not even if you insist.

So my older, smaller projects will run on PHP 4.X or PHP5.X until hell freezes over and customers can rely on it as always. The bigger projects that require performance and stricter object-orientation surely will evolve, because I think that is a good idea IN THIS CASE. Of course its more fun to make a problem out of it all. But there is no need. There is nothing decided yet and WWW does not equal PHP, anyways. We will survive.

Humble,
me

I am afraid you are misunderstanding me. My comments are precisely to defend developers that do not have a programming background and "work for less than programmer wages" to use your own words.

The matter is that at least in the beginning those PHP developers adopt solutions that are less than ideal, like using the mysql extension functions all over their code instead of using a wrapper class that makes it easy to change in the future.

So, you may lower your gun because I was actually defending you, not the other way around as you misunderstood it.

As for hosting companies that let you use whatever version you want, that usually does not happen when you just pay for shared hosting fees. Obviously if you pay higher fees for a VPS or dedicated server, you can choose whatever version you want even if you have to compile PHP and the Web server by hand.

If you have found an hosting company that lets you choose any version you want just paying low shared hosting fees, be happy because that is an exception.

Thanks for the quick reply. So for me as someone not deeply involved in the process of evolving PHP there is an easy solution - just pay that few bucks more to remain free / to be able to choose PHP versions.
From my "not a programmer" point of view I ask: Isn't it possible to use an interface class, that catches the errors and keeps the old mySQL functionality alive with a few changes in code?
Sure you are right about low shared hosting fees by small packages. Maybe these companies will think twice before losing customers by using a new stable that crashes most applications - the may stick to an older version, because the least of their customers run big important resource monsters.

I think most visitors of this site surely stay on the more serious and reasonable side, and there will be solutions for you here as there will be for the others around. Deprecating "var" and deprecating the mySQL Plugin does not play in the same league, it is barely the same sport, don't you think?

All guns down (the cannons too),
Erik