Not really

First of all, i think the first example, the one mentioning var declaration of properties is wrong. We already have a ton of inconsistencies in php, and var would be another one added to the stack. You would have var, protected, private. Can you tell at a first glance what var is supposed to say about that property? excepting the fact that it's a "variable"?

Second of all, noone forces you to migrate php4 code onto php5. If anyone forces you to do that, then that anyone should be ready for refactoring, and on a massive scale. IMO php5 being backwards compatible is really really wrong. Such a major shift in php shouldn't have sustained old code. But then again that's just me.

From my point of view, using pdo/mysqli looks better in a OOP environment. It gives a feeling of consistency.

In short words, i cannot see what the problem is in marking functions in the original mysql deprecated and eliminating them later.

I am afraid you missed the point. PHP should not be reporting notices on things that are not wrong, even if in your opinion they do not look consistent.

If PHP throws notices on things, companies need to spend money hiring developers to fix code that causes the notices. That is why many, many sites refused to move on to PHP 5.

They just did not want to spend money fixing things to make it run without notices in PHP 5, when in PHP 4 it was already working well as ever.

PHP core developers realized that one those pointless notices was with the use of var. Using var is not wrong. That is why later they removed the notices for the use of var.

I think you missed the point, Manuel.

I work for huge corporation (ISP) with huge, legacy PHP code written in PHP 3 (yes, 3, it's not a typo). Over these years this sofware was succesfully migrated to PHP 4, and then to PHP 5, PHP 5.3 (last two was done by me). It was not a problem at all, the notices and warnings were hidden by the server configuration, so end users were happy, and I had some time to update the source code. Those warnings were a blessing for me, because by watching the server logs I could easily locate the problems and fix it in few seconds.

It's better to fix the E_DEPRECATED errors, rather than update PHP and see, that you have E_FATAL errors (because nobody told you, that the extension you were using has been disabled).

I think you said it all, you work for a huge corporation that obviously has money to pay for their developers to fix their code whenever is necessary.

That is not the reality of the majority of the PHP sites. Most PHP sites are small and running on shared hosting because the owners cannot afford more than $10/month to keep their sites. They invested some money to have their sites developed and now they have limited budgets to do any maintenance that is not really necessary.

This was the main reason why many site owners avoided upgrading to PHP 5 for as long as they code. It costs money to maintain code, your company can afford it, but many small companies don't.

I understand your concerns about the low budget companies. But try to understand my point of view: PHP must be improved in order to stay on market. The Zend team can't maintain legacy code forever, they dont have enoght resources to do so. I had a phone conversation recently with one of the PHP core team devel and he told me by phone about future plans concerning PHP 5.4+ and their inability to implement UTF-8 in PHP 5.4 because of the various extensions used by PHP. UTF-8! A world encoding standard which is implemented in Python, C#, Java... In PHP you still need to use 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.

And cash... I think you are mistaken... There is plenty of cash on the market, the problem is, that nobody want's to use it to improve existing solutions (are you concerned about a salary of President of board who says "no" to updates, or the simple PHP student/developer who can fix it for a few bucks and make a living?)

I agree.
Php was an alternative for small businesses with tight budgets.
Zend seems to forget about that.
Things that work should not be messed with, as it means a lot of money for small businesses.
And they feel the pinch as it is.
PDO is great (and easy).
OOP is great (and somewhat hard to figure at first).
Switch from procedures to OOP across the board would require humongous amounts of money, which are not there.

If Zend goes for it, php most likely will fork, with Zend playing with "big boys" and someone else satisfying needs of small business.

That would be a shame.

Php has to remember its roots.

I personally feel that this is a case of write once fix many, or perhaps a way of generating more PHP job opportunities.

The amount of effort to maintain working code that has been in the product for a very long time ought to be negligible so the argument of resource of old vs new doesn't seem to fly.

The main problem is that the sheer number of PHP applications that use mysql means that ultimately removing it would be seem like a good idea for a very few, but that action means that all the really good stuff that is new and exciting will not be used by a vast number of people because of the backwards compatibility issue.

The old PHP 4/5 argument is a classic case of expecting everyone to have significant ongoing resource to change applications with new versions, rather than taking the view of keeping compatibility unless there is a compelling reason.

I would have thought that the developers would prefer to have their efforts used by the maximum number of sites and hence a little bit of old code effort to make sure that the much bigger new code features are available to the biggest possible audience would be a the preferred option. To deliberately constrain the available audience for some I had written would be somewhat depressing, but that is just me!

I disagree with you Colin. In one of my companies I was responsible for maintaining old, legacy selfcare system written in PHP 3 (and updated to PHP 5+). It was a total nightmare! From 17 devs only I knew how this thing works (and not even it's original author) but only after 3 years of self-learning . One of the developers had been delegated to learn this system, just to make sure that I can be replaced, etc. He failed ultimately when his modified system has been taken into production. In fact it was an epic fail that resulted in our entire PHP department to be integrated with existing .NET/CRM department (to make sure we are watched more closely).

Old, legacy code is very expensive to maintain, even for large companies. This company assigned us a budget of around 1 mln euro, just to write new selfcare system in PHP from the scratch, because maintenance and future development cost of existing solution was more expensive. It took almost one year of development to create this system, but now - the maintenance cost is almost null, there is statistically only one bug per month, and almost all of the bugs are on the CRM side (.NET), not PHP's frontend.

There seems to be a misunderstanding here.

PHP has improved. MySQLi was added, PDO was added, mysqlnd was added. None of that required removing the original mysql extension.

Another point is that it is not Zend that maintains the MySQL extension. It is MySQL people that is responsible for that. It costs nothing to Zend to keep the mysql extension as it is now. There is nothing to maintain.

Who proposed the change was Philip Olson, who is neither from Zend nor from MySQL as far as I know. He is an editor of the PHP manual. Maybe he does not want to maintain the documentation of multiple MySQL extensions.

As for the concerns about the costs of maintaining sites that rely on the mysql extension, I suggest that you read the remaining comments of this post, so you can realize about what I already explained regarding limited budgets.

Manuel, I could not disagree more with your opinions on this thread. First off:
"Who proposed the change was Philip Olson, who is neither from Zend nor from MySQL as far as I know. He is an editor of the PHP manual. Maybe he does not want to maintain the documentation of multiple MySQL extensions."

Where the hell has this come from?! You're theorising that one of the PHP manual editors does not want to look after the MySQL book anymore and so its pushing to have the extension axed completely?!

Any PHP programmer worth their salt knows that the MySQL extension has been on the way out in favour of more efficiently designed MySQL extensions making use of OOP (which is what PHP 5 is all about).

I completely agree with Artur's statement about legacy code costing businesses (large and small) extreme amounts of money compared to keeping applications up to date. Like an old car, outdated code becomes harder and harder to keep working. You may take the stance that once a system is working, don't touch it. But incompatibilities are introduced all the time through security updates and the want for additional features, the expectation that old code will work forever is quite simply unreasonable.

Now lets just backtrack, you are acting as if PHP are just axing MySQL completely, which is incorrect. Using E_DEPRECATED is the best way possible to get developers to start using the newer extensions (which they have been trying to do in the PHP manual for a while now). Its part of a long transitional period (which started with the notices in the manual).

I've had these articles pinging into my inbox for a while now and it never ceases to amaze me how much anti-developer sentiment you can derive from progressive changes. I suppose we should have stuck with PHP 3 and left it at that? I'm normally never baited into these comments, but your stead-fast arrogance and refusal to accept blindingly obvious, logical changes and statements from other commentors enrages me.