The PHP 7 Revolution: Return Types and Removed Artifacts

My code can only be “improved” by fixing bugs and responding to changes in my user requirements. Taking time out to rewrite a piece of so that it does just what it did before, but differently, is time that I cannot afford to waste.

My code can only be “improved” by fixing bugs and responding to changes in my user requirements. Taking time out to rewrite a piece of so that it does just what it did before, but differently, is time that I cannot afford to waste.

Clearly that is not the case. You’ve spent more time arguing here and elsewhere than it ever would have taken to change the code.

1 Like

That’s unfortunate and likely not a good strategy moving forward. At some point every application gets a rewrite. I’ve been a part of that many times, it was a necessary thing for us to do (as a company) to stay relevant in an ever changing environment/market.

1 Like

Yes, and so are they. The only reason they don’t upgrade as quickly as they could do is because of unnecessary and frivolous BC breaks. 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.

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.