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.
Obviously you have your own agenda here and it isn’t to actually discuss why this decision may have been made and how it integrates with the lifecycle of several companies. With that said, you’ve made it clear you don’t like the direction PHP is going, unfortunately, there isn’t much you can do as it has been decided (from what I understand).
My points weren’t about you or your application, but what other companies do. You have no experience in that regard, that is my experience, so to say it was wrong or incorrect is an impossible statement for you to make. Since you don’t seem to care how others deal with these type of changes and just want to rant. I wish you the best of luck, as you’ll need it to move forward (and should you switch to another language, good luck there too; as these “breaking” changes will continue to occur).
The proposal to remove PHP 4 constructors from PHP 7 was not made because they cause genuine problems - because they don’t - but simply because some purists don’t like them. As for how it integrates with the lifecycle of several companies, this is only relevant if they are currently using PHP 4 constructors and have to change their code. If the are not using them then this proposal will have zero impact.
I am not against improvements per se, but I am against removing perfectly valid functionality for no good reason. The reason that I am still arguing is that the RFC has not yet been voted upon, and my voice may still have some impact on the vote.
If other companies have issues because of the way that they do things, and | avoid those issues by doing things differently, why is it wrong for me to point this out?
Are you the same Tony Marston behind Radicore? Is this an example of what you consider to be well structured and easy to read and maintain code?
Yes. What is the problem with that code? Are the function names and the variable names meaningful? Yes they are. Is the code easy to read? Yes it is. Does it have a simple structure which is easy to follow? Yes it does.
The fact that my code is not written in the same style that you use, or the fact that I don’t use design patterns in the way that you do, or interfaces, or dependency injection, or any of that other OO crap, does not mean that my code is unmaintainable rubbish. I have been maintaining it and extending it for over 10 years without issues. Other people have been using my code for years without issues. They don’t seem to have problems with it, but if you don’t like it my only response is “ask me if I care”.
The only universal definition of “crap code” which you will get out of any developer is “code not written by me”. I’m sure that if I saw examples of your code that I would find fault with it, but such an argument would not be germane to the issue at hand so I suggest we not go there.
I should also point out that I did not post those code samples on that site. The person who did is long overdue for a knuckle sandwich.
Again, you missed the point in its entirety. It isn’t about you! The point was to show you what others are doing today, their experiences, their real life scenarios.
I officially give up on trying to help you see how you can overcome this and will instead leave you to your own internal discussions, as you seem to only want to listen to yourself to begin with. 
Stop making this personal, and look beyond what you’ve done for the past 10 years. To quote Jurassic park, you’ve spent so much time pushing and pushing through requirements and keeping your code “untouched” but you never asked yourself “should you?” 
(I actually like that quote now…)
Actual quote:
“Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.”
The whole point of this discussion is the issue of whether it is right for the core developers to remove something from the language for no good reason - in this case it is PHP 4 constructors - or whether they should leave it in and move on to something more important. You, and others like you, keep telling me that I shouldn’t be using PHP 4 constructors because they are obsolete (which is technically wrong) and instead of wasting my time arguing I should simply get on with changing my code. That attitude sucks, and telling me about the problems that other developers have each new PHP release will always provoke the response that I don’t have the same problems as they do because I work differently. I don’t have a problem supporting different PHP releases with different versions of my code because I can support all releases with a single codebase.
As for that movie quote, it can also be applied to the core developers.- just because they have the power to break BC does not mean that they should. It can also apply to each new PHP release - just because it contains new features does not mean that I have to use them.