I was not, no, but I am aware of quite a few shenanigans from the internals discussions - it’s often been a tragicomic adventure. : )
I believe the argument here is that Tony likes to keep the PHP version up to date, but not the code. In other words, the effort it takes to modernize the code to best practices as recommended by the internals group is not worth it, while the effort of upgrading to a new version of PHP (arguably taking longer), is.
I can sort of relate to this, to each his own after all, but it still seems like resistance for the sake of resistance.
I do completely agree with Tony, however, that a deprecation notice should be implemented first, before removing functionality that can cause BC breaks. It’s simple custom and good manners. Let’s hope the PHP 5.7 vote re-opens soon, and that the meta-version comes to life for the sake of easier adoption. PHP 7 is shaping up to be absolutely amazing, and it would be a shame if all those stuck on horrid old code were abruptly left behind unable to upgrade versions just because of inertia.
There are two degrees of “hurt” when you break BC.
The first is if you do any BC breaks at all you need to involve a developer to do an upgrade. That’s problematic for existing deployed software, because there might not actually be a developer around. At that point, it may make more sense to switch to a different platform / solution entirely. Any BC break in PHP therefore leads to users abandoning the platform. Meanwhile, you don’t gain any new users, because supporting less syntax never wins someone over. Only if you break BC to introduce new and amazingly improved syntax do you gain users. Breaking BC loses you users but doesn’t win you new ones to replace them. Maybe those lost users are the kind you don’t want, but still, it happens and it is a choice platform owners must make deliberately. For me this would be a reason to never drop support for old syntax unless it is needed to introduce new syntax. I would have kept the old constructor syntax in.
The second is death by a thousand paper cuts. Every BC break adds cognitive load to the developer supporting their software. Each time you need to change, and retest. Real world software does not have perfect unit test coverage, so costly manual testing is necessary each time, which you shouldn’t force your users into unless it’s really necessary. That’s why when you need to break BC, you should do it all at once, so for me PHP 7 is a good time to do it. However, that does not mean that breaking BC in every PHP release is a good idea. PHP’s strength is BC support. Let’s not lose that.
Finally, let me mention that if PHP had LTS releases this issue would be much less critical. If say PHP 5.6 was supported for 10 years after its initial release (similar to what Microsoft would do with their server products), then people could migrate those codebases as part of the natural upgrade cycle that befalls all software. Again this is a choice you make as a platform. Drop support quickly, and you bleed users but have the agility to win new ones through building a better platform. Drop support slowly and you have a larger user community, but platform improvement must happen orthogonal to existing syntax.
All I would ask for is for choices around BC to be made deliberately and with due consideration to the difficulty of finding resources to adapt a codebase to changes in the underlying platform when the business owners want us developers to be building all features all the time.
I often wonder why they don’t have a simple ini_set command to essentially say “I want BC” as they did with ini_set(‘zend.ze1_compatibility_mode’). This is a best of both worlds approach as it allows people to upgrade their PHP version and at the same time, individual scripts can easily be fixed by a single line at the top of the page.
Alternatively do it like Perl with “use strict” and have it enable a set of BC breaking features. Anyone who develops with this flag turned on knows what they’re doing. Even better, make it a per-file flag and all problems are solved.
No, because their applications will more that likely stop working because of a BC break.
They are still running older versions of PHP simply because their customers’ applications won’t run on the latest release due to all those BC breaks.
PHP 4 constructors are still fully supported in PHP simply because they have NEVER been marked as deprecated, so to say that they are obsolete and should not be used is just plain WRONG!
[quote=“mAAdhaTTah, post:40, topic:110202”]
and if the current method of using them can cause conflicts, [/quote]
The only “conflict” that has been reported is where a newbie programmer creates a class method with the same name as the class, and without a separate __construct() method, without realising that it automatically becomes the constructor instead of a separate callable method. Such newbie developers should RTFM (Read The Friggin’ Manual).
The downside is all the unnecessary refactoring that developers have to go through in order to upgrade to a new release because of a frivolous BC break. I use the term “frivolous” because it is not to solve a genuine bug or security issue.
There simply needs to be an ini switch which enables php4 constructors and all these issues are solved. It’s off by default and people with legacy code can enable it. Newbies don’t get confused, the manual can be simplified and anyone who really needs this behaviour can enable it.
I agree that breaking BC for everyone is not really a viable solution. It causes problems because someone can’t simply upgrade PHP on a site without investing time redeveloping parts. Clearly that’s not good from a business perspective. The result of this is that old PHP versions stay on servers running old sites, which then become security issues because updates are no longer issued for those versions.
Breaking BC for everyone is a bad move but so is keeping BC for everyone.
FWIW: It would take about 10 minutes to write a script that updated all PHP4 constructors in .php files to use the PHP5 __construct()
Correct. I want to ensure that I am up-to-date with all bug fixes, but I do not see why I should be forced to refactor my code for an unnecessary and frivolous break in BC. If it is a choice between a single core developer doing an hour’s work and 240 million website owners doing an hour’s work each then which would you describe as being the most cost effective?
Wrong. I am complaining about being forced to do some unnecessary refactoring because of a frivolous break in BC.
Your use of the word “horrid old code” is entirely subjective and unnecessary. Code does not have to be “pretty”, it has to be “effective”. Ugly code which works is far better than pretty code which does not. I do not like having to refactor my code just because some junior programmer has taken it upon himself to redefine what “pretty” means.
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.
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.
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).
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.
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.
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.
