The PHP 7 Revolution: Return Types and Removed Artifacts

Why, breaks in BC of course.

I’m interested to know how you arrived at this claim. There’s numerous reasons people may not upgrade: 1) they may not see the need. They got their wordpress site working there’s no reason to ever touch it again. 2) Their OS may not provide an update to the latest version. I believe CentOS 6 only provides 5.3 for example, plesk is terrible at providing php updates. 3) Lots of people have an ‘if it aint broke don’t even touch it’ attitude so will just leave the server as-is until something breaks.

Not only that, those stats are somewhat flawed. As people have become more security concious they’ve stopped their servers reporting server-side technologies used. This will inflate the statistics for older, rarely maintained servers where the defaults are set to report the tech used.

1 Like

But not every 12-18 months because of breaks in the language. An application usually only gets rewritten in the same language when the existing codebase cannot be maintained, or because of a drastic change in user requirements. In some cases an application gets rewritten because it is the only way to move to a new platform, but in that case it may also mean a change in language.

The average life of an application is said to be about 7 years, and some have been known to last much longer than that. My framework has existed for over 10 years but it is still going strong because I actively maintain it with a new release virtually every month - and with an amazingly small number of BC breaks. My major ERP application is seven years old but it is still going strong because I actively maintain it. By “maintenance” I mean fixing bugs and responding to user requirements, NOT by refactoring my code just because some junior developer with OCD has had a brain fart and removed something from the language that did not NEED removing.

If I, a doddering old fart from the age of the dinosaurs who started his career on COBOL, do not have any problems dealing with such minor and trivial inconsistencies, then why can’t a youngster who is obviously not long out of school do the same thing?

Wait, there are BC breaks between 5.3 and 5.4?

If you look at http://w3techs.com/technologies/details/pl-php/5/all you will see the following for PHP usage:

  • 19.5% of sites are still on version 5.2
  • 45.5% of sites are still on version 5.3

That means that 65% of PHP users are at least 3 releases behind. Is this an issue or not? And what causing this situation? Why, breaks in BC of course.

What you are saying isn’t making sense.

PHP 5 has existed since 2004. So PHP 7 isn’t a breaking change that was created within 12-18 months. PHP 5.0 through 5.6 has likely had very few breaking changes. You typically don’t introduce big breaking changes in minor versions.

PHP 5 to PHP 7 is a major version change, those definitely have breaking changes (PHP 4 to PHP 5 had several too). Your framework has been 10 year strong because, well PHP 5 has been out for 10 years. It has nothing to do with the lack of breaking changes, you simply haven’t crossed major versions yet.

I wouldn’t suggest doing that, as you’ll still have this problem with breaking changes. .NET, Java, Python, all implement breaking changes at major version upgrades.

You obviously have zero respect for those that created the language if that is what you think happened. I strongly suggest reading my earlier post as to why breaking changes are a necessity for any language.

No it didn’t. That is another flaw in the original argument. :smile: All minor versions in 5.0 to 5.6 would have rarely had a breaking change (I bet you can count them on one hand – if even that many existed)

1 Like

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)