The PHP 7 Revolution: Return Types and Removed Artifacts

This was discussed on the internals list and rejected. Quite rightly, as far as I am concerned.

Why is keeping BC for everyone bad?

That’s still more effort than would be required to leave them in.

Because it gets in the way of the language evolving and improving. It would be very nice if PHP fixed the inconsistently named str* functions but they can’t because of BC.

10 minutes every 10 years doesn’t sound bad to me. PHP4 constructors have been referred to as “old style” in the manual for quite some time (Possibly even since PHP5 was released)

I am grateful that you have taken it upon yourself to engage in this topic. I know how much effort it takes to argue against such a tide, and standing your ground so firmly is admirable at the very least. I also appreciate and understand that you may have code you don’t feel like refactoring, and I completely agree that a feature should be marked deprecated before being removed. But I assure you, and I say this with the utmost sincerity, that I am junior to you only in age. That is not to say I may outdo you in this or that kind of task, but that I have seen and dealt with enough code, both legacy and up to date, to be able to objectively conclude which code is and is not pretty. One might argue that beauty is relative, and prettiness of code in peers of the similar level of experience may very well be, but generally, a senior will likely be able to recognize pretty (and, by extension, ugly) code sooner than a junior.

Just as we once considered crinoline supported dresses to be what gives women the default of beauty and elegance, and doctors recommended cigarettes as a good solution to that nasty cough, so too can code standards change and we can alter opinions on what good, healthy and pretty code should look like. Not based on feeling or a mere whim, but based on research and countless experiences in the field.

I would argue, therefore, that code that has the potential to confuse, even the least bit, is uglier than code which is effective.

2 Likes

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.