The PHP 7 Revolution: Return Types and Removed Artifacts

There must be. No core developer worth his salt would let a major release go by without finding an excuse to break BC for a totally frivolous and unnecessary reason.

That’s the problem. Those are not major releases. They are minor releases.

I’ve found 2 based on my searching (both were created to solve security issues)
5.4.29 to 5.4.30 and 5.5.13 to 5.5.14

Both were rare situations that wouldn’t effect the general mass usage of PHP

Clearly you didn’t read my post. Re-read it. There’s no way to know if BC breaking is the reason for people not to upgrade and those stats are flawed because they will inevitably include more older servers than newer ones.

Just because other languages do it does not mean that PHP has to follow suit.

While a break in BC may be necessary to fix a bug or security issue, a break for any other reason is frivolous and unnecessary.

There is no way to know the exact figures, but that does not prevent anyone from making an educated guess based on the information available.

Fairly certain I provided many valid reasons…

Surely you have to do similar tactics within your own framework, otherwise you end up supporting legacy implementations for way too long, which ultimately slows your development/QA process.

1 Like

There is no way to know the exact figures, but that does not prevent anyone from making an educated guess based on the information available.

The problem is your guess is not “educated” it’s entirely unsubstantiated.Do you think people are more likely to still be on 5.3 because of BC changes or because the repo their server is using e.g. CentOS 6 simply doesn’t provide an updated version. Your claim is baseless and more likely incorrect than correct.

Sorry, this is me being a “smart-***” (so don’t take this too seriously), so if I guess “It is because the solar panels of the international space station are being affected by cosmic radiation and that limits the communication here on ground with the rest of the team” does that mean my guess has as much merit as yours since I derived it from the same data elements of 65% still haven’t upgraded?

No, it still is a completely wild guess with nothing backing it. :smile:

1 Like

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.
.