Hey Tom, how about suggesting it? It’s not like the PHP team are against good ideas.
Scott
Sorry Tony, but what is it? An important BC break or a minor inconsistency in the language?
I have never seen anybody in my life make such a lot of noise over some work they might have to do. Your 240 million sites using PHP may be a correct number, but I’d bet you, if you could prove it, that very little of them use the old PHP4 constructor method. And if they did, they can sit on PHP5 until they die, if they want to, just like you.
In other words, just about anyone here who programs wants to program in a better language and one they can also be proud to say they are a programmer of that language. To do that, old inconsistent ways need to be removed or improved. That is what is happening. Accept it and you and us all will be better off.
Also on the deprecation part. I am also in agreement that a function should be deprecated with a warning first. But, it is now Jan, 2015 and PHP 7 should be released at the end of the year. How much more warning do you need and will you upgrade to PHP7, right when it comes out? Probably not. So the deprecation issue isn’t really a big one or really one at all. You know the change is coming. You can deal with it and should, instead of making a lot of noise only a minority of people agree with and basically wasting our time and yours. You probably could have refactored your code in the time you’ve taken to rant all over the Internet about this. Go get to work. I am.
Scott
I think a realistic question here is that even if PHP 7 is completely backward compatible with PHP 5.6, how many people will actually upgrade. If you consider most are still on PHP 5.3 or 5.4, and about 15-20% still use the old fashioned PHP 5.2(which my own software no longer supports even), you will get the idea. I dont think backward compatibility is a big issue here, unless it breaks way too many old things(just one old-styled constructor removal is of little concern). The truth is that most big companies with legacy softwares will stay with PHP 5.2 or even PHP 4 anyway, while a portion of active developers will always embrace the new changes.
As a matter of fact (or should I say “in my humble opinion”?) the proposal to remove PHP 4 constructors from the language is neither. It is not an important BC break simply because it is not being done to fix a serious bug or a security issue - it is being done simply to appease the paradigm police. It is not to fix a minor inconsistency as they are not inconsistent with anything.
I never claimed that all 240 million websites are still using the old constructors, but enough to make a hell of a noise should their applications break when they try to upgrade to PHP 7.
This depends on your definition of “better”. In my humble opinion (and I am not alone in this) it means the same language but with bug fixes, new features and possibly speed improvements. It does NOT mean frivolous BC breaks which cause large numbers of applications to stop working. If developers cannot be confident that their language will continue to provide stability and longevity then, instead of rewriting their application in the old language, they may decide to move to a completely different platform altogether and the new version will never gain as much support as the old version and will slowly die out.
If PHP 7 is so radically different from PHP 5 that it is effectively a completely different language, then it’s adoption rate will be incredibly slow. According to the figures available on http://w3techs.com/technologies/details/pl-php/5/all 65% of PHP sites have still to move beyond version 5.3. How long do you think it will take these sites to move through 5.4, 5.5 and 5.6? You may think that PHP 7 will be “pure” and “clean” but do you want to be associated with a language that has only 240 sites on the web or one which has 240 million? Answers on a postcard to …
According to the rules of the PHP group no function can be removed from the language until it has been marked as deprecated in the manual and produces deprecated messages from the compiler. In the case of PHP 4 constructors neither of these conditions has been met, so they cannot be removed in PHP 7.0. It is also a rule that functions cannot be marked as deprecated in a minor release, and as there will not be a version 5.7 it is simply not possible to mark them as deprecated until version 7. Even after they have been marked as deprecated they must remain for a significant amount of time before they can actually be removed.
Why do you guys think that it’s impossible for the same code base to run on all versions of PHP 5? My framework has been running on all versions up to and including 5.6, and the only change I had to make was to replace the POSIX regular expressions with the PCRE alternatives. That certainly did not make it incompatible with any earlier versions.
If the only way you can upgrade your application from 5.2 to 5.3 is to make it unrunnable on 5.2 then I would have say that your skill as a developer is seriously overrated.
You misunderstood “supports”. He no longer provides support for those that run on PHP 5.2. It isn’t that his application can’t run there, but he won’t spend time supporting any bugs reported from that out-dated version.
You mean he has separate copies of his code which run on different versions of PHP? If I can have a single codebase which can run on ANY version of PHP 5 then why can’t he? If I am supposed to be an incompetent programmer, yet I can achieve this, then what does it say for his abilities (or lack thereof)?
No, again, you are not reading what is written. He simply doesn’t provide any support for those that continue to run his code on PHP 5.2 (think technical support). Stop reading what you want into things.
From a business standpoint you have to drop support for some setups simply because the time and resources required to keep those environments around are not worth it.
I don’t think anyone has made that claim here, so I don’t understand where that is coming from.
Oh my, your argument surprised me. I guess before asking me this question, how about taking it to popular framework community Symfony, Zend 2 and Laravel and ask them why they decide to drop support for PHP 5.2? Or maybe, you should even ask Wordpress why support for PHP 4 was dropped?
Or I guess you didnt really read or bother to read what I wrote carefully. The fact is that older version(1.1 and 1.2) of my script still ran on PHP 5.2, but it was no longer supported for bugs and security fixes, as CPradio hinted above. The newer version(1.3 and the 1.4 still in development) uses namespace, late static binding and closure, which implies a minimum version of PHP 5.3.
Those who stick with PHP 5.2 will have to use an older version of the script, and like I said before these versions are no longer supported. I was generous enough to continue to support PHP 5.3, as I already was forced to give up some neat new syntax only available in PHP 5.4.
If PHP 7 deliver on the performance, which looks very promising already. Its adoption rate on the enterprise and professional level will be very quick even if they decide to add a lot of BC breaks.
I am surprised you do not put more weight on this, since it easily means thousands of dollars saved a month for anyone running a larger system. Even for smaller systems, it can mean the difference between having to move to a larger server, compared to being able to stay on the old one.
1 Like
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.
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.
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 don’t give a toss about those other frameworks as they are totally useless for writing enterprise applications. The only framework I use is my own, and that still runs on all versions of PHP 5 as well as PHP 4. If those other framework developers can’t do the same then perhaps they are the ones who are incompetent.
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.
I don’t waste my time in refactoring my code in order to use new syntax that came out in a new release as it instantly makes that code totally incompatible with all earlier releases. The only time I change my code is in response to a user requirement.
Here I have to disagree. I have spent the last 35+ years designing and building enterprise applications - which are totally different from your common-or-garden websites - and I can say with complete confidence that such applications are very large (with 2,000+ units of work), quite expensive, and the organisations which use them expect them to have a very long life. The developers of such applications simply do not have the time to refactor their code just because of changes in the language, but they DO like having the ability the upgrade to a newer version of PHP which has bug fixes and speed improvements. Breaks in BC are therefore a V ERY annoying and VERY expensive inconvenience.
If the cost of upgrading to a bigger, faster server is less than the cost of refactoring the application then which of these two options would be the most cost-effective?
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).
I see.
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).
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.
1 Like
The current project we are working on, is a little shy of 25,000 man hours at the moment, I am not sure if this qualify as an enterprise application or a “common-or-garden website” using your logic.
I might also mention that seniority does not always equal better, but I am certain that you are aware of this from your extensive experience in the business.
You are right in that this is a cost vs. gain scenario if it is worth doing an update. Though if PHP 7 keep what it promise in speed gains, I am certain my previous statement keep true.
In addition to the actual savings in hardware cost, reducing the number of servers can also mean you can reduce your server management staff, and gain additional savings there. For a larger system/website, we can fast talk about savings in hundred thousands to millions of dollars range.
Even when you have a large code base, refactoring the code to comply with BC breaks does not need to be that problematic. For the planned removal of PHP 4 constructors, you can easily write a script that would automatically fix that in a few hours, which you then can run on the code base. In this case even if you had thousands of classes, it would not cost more to fix this than the time it took to write the script.
For BC breaks that is more severe like POSIX was, writing a script that generate a report can still be beneficial and significantly reduce the time it would take to refactor the code. This would allow you to easily identify the locations that has to be refactored and by this being able to pretty accurately calculate cost of the refactoring (making it possible to make a proper and educated decision if it is worth it to do this or not). Even on legacy applications without Unit Tests, this would allow the team to first create working unit tests for the affected code, before refactoring the code. Finally in the end all that is needed is to verify the Unit Tests passes and you have finished the update.
In my experience a “web site” is open to members of the public whereas an “enterprise application” is only available to members of that organisation
Seniority provides experience which juniors simply don’t have. But there are pros and cons to both categories - some oldies refuse to embrace change while some newbies want to replace everything old with something new without realising the consequnces.
It depends on what has been broken and how long it will take to fix it. Guessing that it shouldn’t take long is just that - a guess - and as reliable as a politician’s promises.
You are still missing the point I have been trying to make from the very beginning that this particular proposed BC break is totally unjustified and should be given the big “E”.
Very few BC breaks can be fixed simply by running a little script.
.
What do you think I do? I have my application running on my PC with a version of PHP, and when a new version is released I download it, install it, and run my application. If it works under the new version without any code changes then it stands to reason that it will also keep running under the previous version. I do not have a separate version of my codebase for each PHP release - one single codebase runs under all releases.
As both my framework and my application will run on any version of PHP then the version of PHP is totally irrelevant. For example, I recently made a small change to my application on my development PC which currently runs PHP 5.6 and I sent that update to a customer who is running the same application on a server which runs PHP 5.2, and guess what? It worked without any problem.
I disagree. It is down to the inability of the developers to have a single codebase that can run on any version of PHP.
My code IS well structured and easy to read and maintain, but that does not mean that I am willing to spend time refactoring it just because some core developer has had a brain fart and broken the language. The only time I spend on reworking my code is when I have to deal with a user requirement, and once I have dealt with that requirement I stop.
I disagree. Unless a new feature has benefits which are visible to the end user then it is a worthless feature. If I have a function which produces a particular result, and after refactoring it still produces the same result, then there is no benefit. In the commercial world any time spent on something which does not show any benefits is time wasted. That’s why businesses have a process called “cost-benefit analysis”.
If you don’t change your code to incorporate a new feature which came out in a new release then you also don’t drop support for earlier releases. This means that supporting older versions of PHP has zero cost.
With other words, you do not think that the codebase on websites like Facebook, Google, Linkedin etc. can be considered an enterprise application? Since they are just “websites open to the public”.
You can just as easily turn that question around, since your justification for the argument does not hold its own ground.
I suggest that you re-read my post, as that was not what I said at all.
At this point, it looks like you are either a troll, or a developer that has lagged behind in the development in the field. In either case, I wish you good luck in your future endeavors.
That’s a horrible assumption with PHP. If I built it from source, you have no idea what extensions or parameters I built it with, so that assumption isn’t good.
That’s illogical. You aren’t “properly” testing issues against the version they were reported in. So the fact you disagree is meaningless to me. I laid out the business aspect of it, believe it or not, that’s your problem. But these are real business aspects to why you drop support for older versions of a language when you build an enterprise application on the given language.
[quote=“tony_marston404, post:138, topic:110202”]
I disagree. Unless a new feature has benefits which are visible to the end user then it is a worthless feature.[/quote]
Boy, seriously, I mean come on. You’re not even trying to read what I write are you? I clearly stated “the benefit they offer outweights what it costs to support the old versions of PHP” It wasn’t specific to “PHP 4 constructors” but any new feature. Pay attention please. You are so focused on one aspect of the language that you can’t see this topic is about more than just that one aspect.
Also, you have to define visibility for the end user here. If I implement a new feature in PHP because it allows me to code faster and get more features implemented more quickly, does that count as end user visibility? They get more on a shorter time schedule, potentially more bug fixes too. Therefore updating my code base to use the feature permitted me to work better and smarter.
Did I not just describe that in my prior post? Fairly certain I did with “the benefits outweigh the cost…” That is the result of a cost-benefit analysis, so yes, I very much covered that.
To your environment, that’s true. For those of us who actually run our code on the version the bug was reported, it has significant cost. I already detailed that too in my prior post. Next time, please read my post before conducting a “you’re wrong” response. I justified everything you claim is wrong with my wording and if you’d simply look past the PHP 4 constructor issue you are experiencing you would have saw that.
Go back, clear your head, and read it again. All of the issues you brought up, I clearly covered in my prior wording.
That is not an assumption, it is a fact borne out by personal experience. I have been following this practice since 2002 and it has never failed me yet.
If my code works the same regardless of which PHP version it is running in, then the PHP version is irrelevant.
That is because IMHO none of the new features released in PHP 5 have any real benefit, they are just a change in coding style or are purely cosmetic. They do not enable me to write “better” code just “different” code which produces exactly the same result.
As far as I am concerned none of the new features is PHP allow me to code faster, just to code differently. Besides it is a function of the framework, not the language, to provide rapid application development, which is why I built my own RAD framework - why else do you think it has “RAD” in its name?
I repeat, my application runs on any version of PHP using a single codebase. I do not have a different version of my application for each different version of PHP, This means that if a customer is using PHP 5.2 while I am running 5.6 I can change my copy, send it to him, and it runs just the same.
If you are one of those less-than-able programmers who has a separate version of your code for each version of PHP then that is a problem of your own making.