The PHP 7 Revolution: Return Types and Removed Artifacts

The language can be improved by adding new features, but the removal of an existing and still used feature will NEVER be regarded as an “improvement” by all those to have to spend valuable time in refactoring their code.

The str* function names are not inconsistent - they are consistent with the names of the corresponding functions within the ‘C’ language upon which PHP is rooted. Besides, the “funny” names do not prevent millions of developers from writing effective programs. I myself cannot remember the name of every available function and it sequence of arguments, which is why I use a proper IDE instead of a primitive text editor.

You must not have any experience with .NET then :smile:

Major versions (based on any version pattern your read) typically do not guarantee backwards compatibility. PHP has been permitting this for so long, it is likely leading to code staleness, redundancy, additional tests, and many hidden problems as they implement the same feature in different ways. It isn’t good for the language as a whole for those reasons, let alone the support time it takes to properly ensure each way a feature can be implemented is working properly.

Don’t get me wrong. I’ve enjoyed PHP since I started using it when it was in the stage of going from PHP 3 to PHP 4, but I’m completely shocked they really haven’t introduced breaking changes across their major versions (to the extent .NET has).

.NET 1.1 had many breaking changes when going to 2.0, then it had a few more going to 3.5 and 4.0 introduced even more. All of the changes actually have been better for the language. It standardized a lot of the internal classes of the framework and it speed up the CLR by allowing it to do less processing.

Their support time increased and their development time for patches also saw improvements since they didn’t have to support the initial implementations that existed way back in 1.1. As a whole the language was in better position to tackle “how can we help our developers use this language going forward” versus “how do we ensure we don’t break X which still exists from 2-3 versions ago”.

As a developer, I write a lot of APIs (that is probably 80% of the work I do on a regular basis). If I had to support v1 of the API and keep it running through v4, I’d go crazy. The amount of bloat that would add, the strain it would be on our QA department, and the little benefit it would really have for our users isn’t worth it. There are reasons why changes were made, to provide a better overall experience/performance boost.

You may see it as unnecessary changes, but really it is a gateway for you to radically improve your codebase and reconsider some of the legacy aspects of your product. What you did back then, might not be the best approach, best performing way today (I know code I wrote in PHP 4 definitely wasn’t the best approach to what exists today).

2 Likes

So you’re expecting developers will upgrade to PHP7 and leave their code exactly as-is? But we shouldn’t fix this conflict b/c it caters to newbie developers?

I mean, PHP7 is a major release; while I don’t know for sure, I’m extremely doubtful the only change you’ll have to make to your code to make it work with PHP7 is changing your constructors. If this is one of several BC-breaking improvements to PHP, I really don’t see why this is an issue.

Beauty will always be in the eye of the beholder. To me “pretty” code is easy to maintain because it is easy to read which also implies having a proper structure. Code which is unreadable is not pretty. Code which does things in a clever and complex way instead of a simple and straightforward manner is not pretty. That is why I follow the KISS principle and write enough simple and well documented code to do the job after which I stop adding useless code.

While the fines details in the many sets of coding standards may change you must remember that there is no single set of standards which is universally accepted by all programmers in all languages. That is why I concentrate on the bare essentials and refuse to waste time arguing and nit picking over minor details of personal taste. My bare essentials are

  • the code has to be readable with meaningful variable and function names.
  • the code has to be well structured, and the structure has to be logical so that anyone looking at a structure chart can quickly see what goes on where.
  • simple code that anyone can understand will always be better than complex code that only a genius can understand.
    Arguments about the use of camel case instead of snake case, for example, I simply dismiss as trivial and irrelevant.

They clearly are. str_replace is inconsistent with strpos one has an underscore the other doesn’t. The fact they’re based upon c functions is irrelevant to a PHP programmer. It’s yet another hurdle developers have to remember along with bizarrely inconsistent parameter orders ( substr and strpos take the string being worked on first, str_replace takes it as the last parameter, it’s stupid, pointless and easily fixed).

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.