The PHP 7 Revolution: Return Types and Removed Artifacts

[cpradio]

@tony_marston404

If the same codebase runs on 5.0, 5.1, 5.2, 5.3, 5.4, 5.5 and 5.6 it is illogical to say that you don’t support the application on anything less than 5.3 (or whatever). Bugs which exist in PHP and not the application are the only bugs which require a change in PHP version.

Not the point I’m trying to make. To properly test PHP versions, you need several things. 1) that version of PHP installed, and 2) your code base installed on that server as well.

That gives you a few options, 1) setup VMs (slightly expensive), 2) physical servers (most expensive), or 3) Vagrant (which is still VMs, but can easily be torn down)

For all of the options above, you still have to spend time setting them up, ensuring your codebase is installed properly, database seeding so you have data to work with, etc.

I’m purely saying the effort to properly support older versions of PHP at some point becomes too expensive and therefore, businesses drop support for those versions. Their money is better spent on more up-to-date versions that their internal servers already run on, or were upgraded to.

I know many places that only support the last 2 or 3 5.X versions of PHP. Because that is what they choose to have as physical/VMs/Vagrant setups in their environment.

This is purely a business/financial problem, not a coding problem. Sure the code may run on older versions, but the time you invest and pour into properly looking into issues on those older versions is downright expensive (if you choose to test it right and run it on the actual version the bug/problem/issue was reported on).

@tony_marston404

I am currently defending my position in two different forums - this one and LinkedIn - and my critics (of which there are many) keep telling me that if I continue using what they regard as an obsolete feature, if I don’t follow their version of best practices, or if I don’t completely refactor my codebase with each PHP release to incorporate new functions then my code must be crap and I must be incompetent.

I see.

@tony_marston404

It is NOT a programmer’s job to write code to impress other programmers, it is to provide the functionality which is required by the customer in the most cost-effective manner. When I write code in response to a customer request I write enough code to get the job done, then I walk away and start on the next user requirement. I do not go back and revisit an existing module unless I have a good reason to do so. This is a long standing philosophy called “If it ain’t broke don’t fix it”.

I’m not 100% in agreement here, because as programmers one of our jobs is to write maintainable code too and to write code that is easy to understand/update, which means refactoring it should be easy.

Any time I get a new feature request, we look to see if where that feature is going to reside can be refactored to better incorporate what the original requirements were for that area to what we are adding. I can only probably say a small handful of times we were not able to refactor the code to function better given the new feature we were implementing and how it played into existing logic/code (and maybe you do this too, as you didn’t specifically say you don’t).

@tony_marston404

I never bother using new features as soon as they come out - such as namespaces, late static binding and closures - so my single codebase is capable of running on any version of PHP.

Look at it from the other perspective. The ones who choose to use them, do so, because the benefit they offer outweighs what it costs to support the older versions of PHP. It isn’t only because they want to use latest and greatest, if they are anything like the projects I’ve been a part of, there is an uphill battle discussion the benefits those features contain because doing so, would definitely drop support for older versions of PHP. Although it isn’t a difficult argument to show that properly supporting old versions of PHP is expensive, not many companies jump on that right away, but when you show the numbers and the cost savings, it is hard for a company to argue too much that they are throwing money down the drain that could be used towards implementing larger features sooner than later.