The PHP 7 Revolution: Return Types and Removed Artifacts

With PHP fighting against HHVM and speed becoming an increasingly important factor, having PHP look for two different functions each time a class is constructed is redundant and inefficient. Not only that, the PHP4 implementation has been noted as “old” throughout the manual. They barely mention it in the docs and the number of people affected by the change is minimal because every code example written after about 2004 uses the PHP5 syntax.

Then your understanding of the release numbering system is flawed. Going from 5.3.x to 5.4.x is a major release. Going from 5.3.x to 5.3.y is a minor release.

If you look at http://php.net/manual/en/migration54.incompatible.php you will see a whole page full of backward incompatible changes for the move from 5.3.x to 5.4.x. There are similar lists for all the other major releases.

How many servers run HHVM? What is their market share compared with the 240 million sites running PHP?

Define “inefficient”. Where are your benchmarks to prove the saving that the removal of PHP 4 constructors would bring?

But it has NEVER be marked as deprecated.

Define “minimal”. What are your sources?

But that does not mean that every piece of code written before then using PHP 4 constructors was magically changed to the new way.

And as you can see, all of those changes are things that have improved the consistency of the language or removed things that otherwise get in the way of what a developer wants to do. These BC changes are progress, not only that they’re either very little utilised features or features which have been downright discouraged for years.

No, fairly certain you are wrong on that.

Major.Minor.Release.Build

Many drop the .Build purely because that is only useful to developers, which leaves Major.Minor.Release

5.3 is a minor release of the PHP 5 language. So is 5.4. Then you have 5.4.1 which likely have hotfixes found in 5.4.0 (or prior minor/release versions, such as 5.3.4).

2 Likes

There’s no way to accurately answer that. However, it’s irrelevant. The fact is, PHP does have a fight on its hands here and it needs to keep up. PHPNG simply wouldn’t have happened if it wasn’t being pushed by Hack.

Needless to say, as developers this is a good thing because we get much needed improvements to the language we use every day.

Define “inefficient”. Where are your benchmarks to prove the saving that the removal of PHP 4 constructors would bring?

if (method_exists($class, '__construct')) $class->__construct();

is always going to run faster than

if (method_exists($class, '__construct')) $class->__construct();
else if (method_exists($class, $class->name')) $class->{$class->name}();

You could scan the class once and store the result of the if statement (using extra memory for each defined class) or do it each time an object is instantiated. Either way it’s going to result in either higher memory usage or more processing

Define “minimal”. What are your sources?

I’ve looked at probably hundreds of PHP libraries over the last few years, I’ve not seen PHP4 constructors used once. Have a look at PHP projects on github, I bet you can’t find even 10 of the thousands on there that are using PHP4 constructors (and are not clearly using the php4 object model, e.g var $var)

Why should anyone have to? My great grandparents did not have problems dealing with a house without central heating, why shouldn’t the current generated be expected to do the same?

You’re actually arguing in favour of inconsistency? I’m convinced you’re trolling now.

They are not an “improvement” if they cause unnecessary work. Besides, removing so-called inconsistencies from the language I would not consider as necessary. They do not cause as much of a problem as having to refactor code for no good reason.

As a developer who gets paid by delivering effective software to my customers the only thing that I want to do is deliver effective software to my customers. That involves responding to the requirements of my customers, NOT the requirements of the language developers.

Progress which causes too many BC breaks will be adopted only slowly.

You have no idea how many applications still use PHP 4 constructors, so you have no basis to claim that their usage is minimal. What percentage of the 240 million websites would you call minimal?

“Discouraged” is irrelevant as the feature under discussion has never been marked as “deprecated”, therefore it must still be supported.

Neither do you, however since you’re the one arguing that they are used the burden of proof falls on you to show they’re utilised by enough people to warrant keeping the feature. I cannot prove a negative (that they’re not widely used) but what I can do is look through projects on github and say there’s very few php developers writing code using PHP4 constructors.

Let’s also keep in mind here that the set of users who will be affected are the ones who:

a) Use PHP4 constructors
and
B) Want to upgrade to PHP7

We already know that a lot of people run old PHP versions, likely because they have no reason to upgrade, their OS will never support the new version or they simply don’t know they can. I’ve had many clients who’ve had enough technical expertise to buy a cheap web hosting solution that offers mutliple php versions, stick wordpress on it then leave the site running indefinitely without even knowing there was an option to update the php version (or even more likely, what php even is). These users will never upgrade until they are pushed, yet you’re counting them all in your irrelevant statistic.

I’d wager most sites running old versions are in this category and use off the shelf CMS software. What I also know is that such software does not use php4 constructors making the number of affected users look increasingly small when both of the above are taken into consideration.

So the difference between a language that is used on 240 million website and one that is used on less than 24 is irrelevant? A fight between an elephant and a mosquito will not be much of a fight.

I have seen the list of improvements in the internals list, and I am in favour of all of them. However, none of these “improvements” require the removal of PHP 4 constructors.

It sounds like this problem could be fixed by https://wiki.php.net/rfc/default_ctor if it were amended to include (the still supported and as yet undeprecated) PHP 4 constructors. You see, it is possible to fi the problem without resorting to a BC break.

Oh I see. Your statement is based solely on the numbers of scripts that you have personally seen. Are you aware of how many PEAR components were written for PHP 4 and have never been updated to use PHP 5 constructors? I have seen posts from other developers in other forums who have large applications which were written using PHP 4 constructors and who simply don’t have the time to refactor them.

So don’t upgrade until time becomes available? See I can fix problems too :slight_smile: (really need a sarcasm smilie here)

Your analogy is worthless. Comparing changes in methods of central heating with dealing with minor inconsistencies in a programming language just does not carry any weight.

I certainly would not be in favour in creating any new inconsistencies, but I am not in favour of breaking the language to remove minor inconsistencies that have existed for decades and which do not cause problems for most developers.
.

I think this is going to be the most important part. I’m really inclined to doubt this is a significant number of people.

Is anyone still using PEAR? PHPUnit just deprecated its PEAR install, and I’d much rather use Composer than PEAR for basically anything.

Edit: Let me rephrase: is anyone who is going to upgrade to PHP7 still using PEAR?

Anyone who’s starting a new project is not using PHP4 constructors. Anyone who’s got a legacy project isn’t going to upgrade to PHP7. I really fail to see what the issue is.

I would suggest removing PHP4 constructors isn’t going to cause problems for most developers.

2 Likes

If they have time to upgrade the server and then check all their code for bugs (You can never just upgrade a library and assume it will work, undocumented bugs do creep in) then they have time to write a (or even download someone else’s) script that recursively opens .php files and replaces the constructor. The “it takes time” argument is irrelevant, the amount of time needed is so insignificant compared to the time taken to test the software against the new version that you simply cannot use it as an argument.

Out of interest, how do you feel about the removal of mysql_* functions? I’m fairly certain these are far more widely used than PHP4 constructors and they’re considerably more difficult to locate and fix.

But not all projects are on Github, so your figures are not a representative sample of the entire PHP community.

Perhaps they will want to upgrade to keep abreast of all the latest security and bug fixes.

But perhaps it will cause a problem for more than a few. How many complaints will it take you take notice? How many will not know that they can’t upgrade until it’s too late?

You may think that the time it takes to fix this is irrelevant, but I and those others who are affected (or find out that they are affected when the news spreads) do not.

That doesn’t bother me at all. As I have already said in a previous post I changed my framework to allow the use of either the original or the improved extension for MySQL as soon as MySQL 4.1 was released and the “improved” extension became available. My code will use the new extension if it has been loaded, but fall back to the old one if it has not. I did not wait until the old extension was marked as deprecated before I made that decision because there were genuine reasons to use the new extension. There are NO such genuine reasons for removing PHP 4 constructors.

That doesn’t bother me at all. As I have already said in a previous post I changed my framework

Then you have shot down your own arguments here and proven that your position is entirely from an emotional and nostalgic perspective. The fact that you happen to use PHP4 constructors and don’t want to use __construct() is the basis for your argument here.

If you were really interested in arguing for “backwards compatibility” then you’d be arguing tha mysql_connect should just be rewritten as a wrapper for mysqli_connect; function mysql_connect($args) { mysqli_connect($args); }

Let’s put it this way, the only valid argument here is that it would mean some developers have to change their code. However:

  • Changing a codebase would take minutes (There was even mention on the mailing list of providing a script that did it for you), considerably less time than testing the code against the new version

  • The majority of developers do not use PHP4 so will never be affected

There’s not really a case for keeping them. Having two ways of doing the exact same thing is pointless and just adds bloat to the language.

Again, so we’re expecting them to upgrade versions but not their code? Come on…

2 Likes

That is PRECISELY what mature and experienced developers expect from their language.- stability and longevity. They expect new features and bug fixes, but not BC breaks. That it what I got from the two languages I used before I switched to PHP. Languages which keep breaking working applications are signing their own death warrants.

If this situation carries on I shall have to write an article asking if PHP can ever be regarded as an enterprise–ready language, because it sure ain’t behaving like one.