# Dragging the legacy users forward. - Thread: https://externals.io/message/82095 - Original archive: https://news-web.php.net/php.internals/82095 - Started by Lester Caine on 2015-02-07T12:36:34+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #82095 — Lester Caine — 2015-02-07T12:36:34+00:00 URL: https://externals.io/message/82095#82095 My personal experience of PHP4 is simply one of having been developing all my code in PHP5.0 to 5.2 but ensuring that the code also still run clean on the PHP4 host. It was not until 5.3 that it was necessary to freeze the code base for 5.2 for every PHP4 host and maintain that fork while 'taking advantage' of the new features of PHP5 that were not supported by PHP4. That is the code base that is currently populating the vast majority of PHP powered sites still, so while PHP4 is dead it's footprint still lives on. Moving code to a post PHP5.4 host is NOT simply a matter of configuring the configuration to hid the problems. Many features relied on by code up to 5.2 had been removed and so code HAS to be reworked ... or hosting remains with some pre5.4 compromise which accounts for the current usage of PHP5.3 PHP7 is proposing a LOT of shiny new features which will break much legacy code. So the question has to be just what is the plan regarding cross version support. I see that the general consensus is PHP5 should just run? But do we have to start taking greater care of third party libraries which as with the 5.2 to 5.4 switch means that two versions are needed? I've currently deliberately configured my development system so that PHP5 and PHP7 are running the same code set and once I have all the missing extensions I can start playing further, but I need to work out how to allow 'needs PHP7' libraries in parallel. There IS a clear speed advantage, but I'm not sure yet if that is PHP5.4 to later 5.x or simply 5 to 7 improvements. I'm don't see any reason to think it's not simply 5->7 so I can then check the impact of things like 'unconstrained integer', however THAT is going to require a lot more care with the code than simply 'it runs' :( In the past using 32 bit builds has been a fix for many problems, not just the windows platform ones, so removing that prop requires a lot more care! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #82120 — Yasuo Ohgaki — 2015-02-08T06:37:46+00:00 URL: https://externals.io/message/82095#82120 · In reply to: #82095 Hi Lester, > PHP7 is proposing a LOT of shiny new features which will break much > legacy code. So the question has to be just what is the plan regarding > cross version support. I see that the general consensus is PHP5 should > just run? > Do you mean release 5.7 or extend life of 5.6? I'm +1 for both options. Extending 5.6 life may achieved consensus. Perhaps, 2 year security support? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #82131 — Lester Caine — 2015-02-08T09:54:16+00:00 URL: https://externals.io/message/82095#82131 · In reply to: #82120 > Hi Lester, > > PHP7 is proposing a LOT of shiny new features which will break much > legacy code. So the question has to be just what is the plan regarding > cross version support. I see that the general consensus is PHP5 should > just run? > > Do you mean release 5.7 or extend life of 5.6? > I'm +1 for both options. > Extending 5.6 life may achieved consensus. > Perhaps, 2 year security support? Well I don't remember any such restriction on PHP4? Although there is still a compatibility library to emulate some later features where PHP4 did not provide them. But we are only talking about 'PHP4' being stable up to PHP5.2 and quoting periods here is irrelevant. Nobody is currently taking any notice of the fact HP5.2 and 5.3 are no longer supported and it's that the removal of features was badly managed that has created this problem. From a day to day survival point of view I have to decide what to do with currently functional sites that ARE still on PHP5.2 hosting. The bulk of the sites that have been moved to PHP5.4 still require regular work because people keep finding fault with one mobile device or another not displaying 'bootstrap3' properly which is another major upgrade path that is the MAIN reason for reworking sites and the one that prevents simple sticking plasters to hack PHP changes. I spent most of yesterday trying to get a key component of a financial site into a format that it could even be used on a mobile phone. And failed, so now I have to find another way to meet the LEGAL requirement that the customer has to comply with. So in general no I'm not talking about having to fix PHP5 code to some PHP7 compliant state, I AM talking about current PHP5 code simply working as PHP4 did into PHP5 hosting! CURRENTLY my php7 test site is running PHP5.4 live code so I don't think I'm out of line here, but if something goes in which causes my php7 test site to crash then I would prefer that to be sorted by PHP7 rather than having to upgrade to some as yet unavailable PHP5.x, although I would be more than happy if I can simply amend the live code and make both work. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #82133 — Tony Marston — 2015-02-08T10:24:58+00:00 URL: https://externals.io/message/82095#82133 · In reply to: #82131 "Lester Caine" wrote in message news:54D73248.9030509@lsces.co.uk... > > > > […] > >Well I don't remember any such restriction on PHP4? Although there is >still a compatibility library to emulate some later features where PHP4 >did not provide them. But we are only talking about 'PHP4' being stable >up to PHP5.2 and quoting periods here is irrelevant. Nobody is currently >taking any notice of the fact HP5.2 and 5.3 are no longer supported and >it's that the removal of features was badly managed that has created >this problem. > >From a day to day survival point of view I have to decide what to do >with currently functional sites that ARE still on PHP5.2 hosting. The >bulk of the sites that have been moved to PHP5.4 still require regular >work because people keep finding fault with one mobile device or another >not displaying 'bootstrap3' properly which is another major upgrade path >that is the MAIN reason for reworking sites and the one that prevents >simple sticking plasters to hack PHP changes. > >I spent most of yesterday trying to get a key component of a financial >site into a format that it could even be used on a mobile phone. And >failed, so now I have to find another way to meet the LEGAL requirement >that the customer has to comply with. > >So in general no I'm not talking about having to fix PHP5 code to some >PHP7 compliant state, I AM talking about current PHP5 code simply >working as PHP4 did into PHP5 hosting! CURRENTLY my php7 test site is >running PHP5.4 live code so I don't think I'm out of line here, but if >something goes in which causes my php7 test site to crash then I would >prefer that to be sorted by PHP7 rather than having to upgrade to some >as yet unavailable PHP5.x, although I would be more than happy if I can >simply amend the live code and make both work. > Well said. If it is not possible to have a single codebase that runs in both PHP 5 *AND* PHP 7 then that will be a total disaster. -- Tony Marston --- ## #82135 — Ralf Lang — 2015-02-08T11:43:59+00:00 URL: https://externals.io/message/82095#82135 · In reply to: #82095 Hi Lester, > My personal experience of PHP4 is simply one of having been developing > all my code in PHP5.0 to 5.2 but ensuring that the code also still run > clean on the PHP4 host. Actually, PHP 4 changed a lot of things from PHP3. PHP 5.0.0 on the other hand allowed you to run much legacy code while providing new and better solutions to many problems. PHP 5 lasted about 10 years and the later half of its life cycle actually amounted to pulling in new features which should have gone into some PHP 6 while keeping an aging core afloat on new hardware, new platforms. 32-bit is essentially dead, Itanium is long forgotten for most applications, Arm and x86_64 are standard. In a perfect world, php 5 wouldn't have lasted that long and a lot of userland code would have broken years ago, requiring trivial changes. It was not until 5.3 that it was necessary to > freeze the code base for 5.2 for every PHP4 host and maintain that fork > while 'taking advantage' of the new features of PHP5 that were not > supported by PHP4. That is the code base that is currently populating > the vast majority of PHP powered sites still, so while PHP4 is dead it's > footprint still lives on. A lot of sites sticked with PHP5.3 because they were driven by enterprise platforms which by definition won't upgrade during the life cycle. That had its own costs and aches which are entirely not PHP's fault. > PHP7 is proposing a LOT of shiny new features which will break much > legacy code. Which features hurt you? Which features break code which would have been best practice by php 5.0.0? > But do we have to start taking greater care of third party > libraries which as with the 5.2 to 5.4 switch means that two versions > are needed? I've currently deliberately configured my development system > so that PHP5 and PHP7 are running the same code set and once I have all > the missing extensions I can start playing further, but I need to work > out how to allow 'needs PHP7' libraries in parallel. Are you talking about userland code or extensions here? Which php5 "best practice" feature would be broken by php 7? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 --- ## #82136 — Matteo Beccati — 2015-02-08T11:45:44+00:00 URL: https://externals.io/message/82095#82136 · In reply to: #82133 > Well said. If it is not possible to have a single codebase that runs in > both PHP 5 *AND* PHP 7 then that will be a total disaster. Of course you can have a single codebase running both on PHP5 and PHP7, unless you want to use PHP7-only features. But that doesn't mean that any codebase that currently runs on PHP5 will keep working on PHP7 without any changes. Most of the "modern" codebases probably will though. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #82138 — Lester Caine — 2015-02-08T12:30:12+00:00 URL: https://externals.io/message/82095#82138 · In reply to: #82135 > A lot of sites sticked with PHP5.3 because they were driven by > enterprise platforms which by definition won't upgrade during the life > cycle. That had its own costs and aches which are entirely not PHP's fault. > > > […] > Which features hurt you? Which features break code which would have been > best practice by php 5.0.0? Currently it is impossible to run the PHP5.2 code base on PHP5.4. That is a simple fact. So I can't do between 5.2 and 5.4 what I am currently doing between 5.4 and 7. The code has to be reworked ... so what ever anybody says PHP5 .4 *IS* PHP6 in terms of major breaks. 'Best Practice' is at best dependent on just what style of working a particular faction wants. Is 'strict typing' an example of future best practice? Is e_strict compliant code best practice? It is that which I base the move from 5.2 to 5.4 on. If I add a library using namespaces often things fail to work so I stick with the 'non-namespace' version? Best practice these days is I suppose to be using composer for everything? None of this was around by 5.0.0 days yet the bulk of my framework code is well over 10 years old and at one time one could select you preferred database install and run. Nowadays just keeping a small subset of database engines working is all we can manage. PHP is no longer the simple user friendly base that it once was! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #82158 — Rowan Collins — 2015-02-08T18:33:14+00:00 URL: https://externals.io/message/82095#82158 · In reply to: #82136 > > > […] > > Of course you can have a single codebase running both on PHP5 and > PHP7, unless you want to use PHP7-only features. It may be true right now, but it is not inevitable. There are certain behaviour or syntax changes that could, theoretically, require the same feature to be written differently in the two versions. Luckily, such changes are rare, and are usually spotted and avoided (as with the change to DateTime typehinting mentioned recently), but it's not something that goes without saying. Regards, -- Rowan Collins [IMSoP] --- ## #82159 — Rowan Collins — 2015-02-08T19:00:55+00:00 URL: https://externals.io/message/82095#82159 · In reply to: #82138 > Currently it is impossible to run the PHP5.2 code base on PHP5.4. That > is a simple fact. So I can't do between 5.2 and 5.4 what I am currently > doing between 5.4 and 7. The code has to be reworked ... so what ever > anybody says PHP5 .4*IS* PHP6 in terms of major breaks. We have a single code base happily running on 5.2, 5.3, 5.4, and I think even 5.5, so it is definitely possible with some code bases. There were a few pieces that had to be changed to work right under 5.3 and 5.4, but none for which the new solution didn't also work under 5.2 (or, at least, for which a compromise didn't exist which worked under both). Call-time pass-by-reference was all over the place, for instance, but rarely actually needed, and if it was, replacing it with a pass-by-reference declaration would leave you with something working fine under 5.2. It's frustrating not being able to use new features when you need to support an outdated installation, and finding third-party libraries which support old versions of PHP can be tricky. 5.3 was the big breaking point there, because although we didn't refactor our code to use namespaces, libraries quickly came to be written with them (which is a good thing) so automatically have that as a minimum version requirement. The biggest problem with keeping userland code cross-version compatible is usually syntax - behaviours and standard functions can, if it's really necessary, be worked around by checking PHP_VERSION, or "if ( ! function_exists('blah') { function blah { ... } }". But because there's no equivalent of a C pre-processor, you can't work around syntax which wasn't valid on older versions, other than by not using it (it would have been lovely to include closures in code which was simply unreachable on 5.2 hosts, but if 5.2 needed to parse that file, it was impossible). Clearly, your experience is different; perhaps some specific examples of the problems which forced you to fork the codebase, rather than adapt it into a cross-compatible state, would help people look out for the same situation arising in future. Regards, -- Rowan Collins [IMSoP] --- ## #82171 — Lester Caine — 2015-02-08T20:53:09+00:00 URL: https://externals.io/message/82095#82171 · In reply to: #82159 > We have a single code base happily running on 5.2, 5.3, 5.4, and I think > even 5.5, so it is definitely possible with some code bases. There were > a few pieces that had to be changed to work right under 5.3 and 5.4, but > none for which the new solution didn't also work under 5.2 (or, at > least, for which a compromise didn't exist which worked under both). > Call-time pass-by-reference was all over the place, for instance, but > rarely actually needed, and if it was, replacing it with a > pass-by-reference declaration would leave you with something working > fine under 5.2. Rewriting the the code to make it work is exactly what is taking the time, but I DID also adopt the standard that e_strict would be required and up until that time all the code I was involved with ran with display_errors ON which was a conscious choice to pick up problems that crept in when they happened rather than having to trawl through hundreds of log files every few days. Remove 'register_globals' and a site breaks until such time as the code is reworked, but that code also needs to be brought up to a better standard rather than simply hacking the register_globals and other removed or backwards incompatible problems. Since a large part of the code I am now supporting I did not write, simply trying to decipher some of the strange tricks coders used to get up to is a nightmare, and some of the new 'styles' of writing things are going to make things considerably worse for those who are going to have to maintain this code in the future. There are several pages of things that were good practice in PHP5.0 code which will now give white screens if one tries to run them on a 'good practice' PHP5.4 setup. Fortunately I think that I've already covered most of the later problems in trying to make the legacy code clean e_strict code so switching from 5.4 to 5.6 should not cause a problem, but I'm not ready to move production beyond 5.4 as yet. If I was only worried about a couple of sites then things would be different, but the current catalogue is some 120 different sites some of which are pigging ASP and I will be glad when I can finally pull them over to PHP. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #82199 — Rowan Collins — 2015-02-09T00:05:17+00:00 URL: https://externals.io/message/82095#82199 · In reply to: #82171 > > > […] > Rewriting the the code to make it work is exactly what is taking the > time, but I DID also adopt the standard that e_strict would be required OK, so that's your choice - you have deliberately set yourself a higher bar than PHP has, in order to end up with better code. Good for you. I can also imagine that setting that high bar may make it harder to make the kind of compromises that are inevitable when writing code intended to run on multiple versions simultaneously. > Remove 'register_globals' and a site breaks > until such time as the code is reworked, but that code also needs to be > brought up to a better standard rather than simply hacking the > register_globals and other removed or backwards incompatible problems. If all you're worried about is running on multiple versions of PHP, the manual includes a one-liner to emulate register_globals. Again, reworking it is a good idea, but not something that PHP actually forces on you. > Some of the new 'styles' of writing things are > going to make things considerably worse for those who are going to have > to maintain this code in the future. If you're writing code that you know will be hard to maintain in the future, you're doing something wrong. If by slavishly following a style guide you've ended up with a poor architecture, you need a better style guide, or a better understanding of why those styles are preferred. Alternatively, I may have misunderstood that sentence, in which case I apologise in advance. > There are several pages of things that were good practice in PHP5.0 code > which will now give white screens if one tries to run them on a 'good > practice' PHP5.4 setup. Maybe, but most of them can be replaced by code which runs fine on both versions. It may not be the best code you could write if you knew you could rely on new features, but it works. For instance, when the preg_replace "/e" modifier is removed, it will still be possible to write code that uses `preg_replace_callback()` with the almost-as-ugly create_function() instead of a real anonymous function. That gives you compatibility all the way back to 5.0, and all the way forward to 7.0; it's also slightly less likely to be a security hole, so you're improving your code base by doing it. If you decide that good code is more important than cross-compatibility, you can go ahead and use the 5.3+ closure syntax instead, but no decision made on this list will have forced that on you. Regards, -- Rowan Collins [IMSoP] --- ## #82209 — Lester Caine — 2015-02-09T01:31:43+00:00 URL: https://externals.io/message/82095#82209 · In reply to: #82199 > > […] > > If you're writing code that you know will be hard to maintain in the > future, you're doing something wrong. If by slavishly following a style > guide you've ended up with a poor architecture, you need a better style > guide, or a better understanding of why those styles are preferred. > > Alternatively, I may have misunderstood that sentence, in which case I > apologise in advance. Something *I* have been asking for for the last few years IS a better 'style guide' ... There are a growing number of 'styles' and the current debate is to allow even more! Just about every framework has a different style of handling database abstraction, and that seems to change every major version as well. All of my own code is based around ADOdb, but now it seems THAT is not an acceptable style of code these days. Anyway I now have PHP56.lsces.org.uk running with the latest PHP5. It's throwing megabytes of data into the error log but there ACTUALLY seem to be less in the php7 error log ... need to figure that out, but I've currently hit the latest brick wall as mbstring is not compiling! Most of the others have compiled fine, but currently there is a blank front page until I can work out what is going wrong ... that and smarty is throwing errors ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #82252 — Tony Marston — 2015-02-09T09:49:43+00:00 URL: https://externals.io/message/82095#82252 · In reply to: #82136 "Matteo Beccati" wrote in message news:54D74C68.6070402@beccati.com... > > > > […] > >Of course you can have a single codebase running both on PHP5 and PHP7, >unless you want to use PHP7-only features. > >But that doesn't mean that any codebase that currently runs on PHP5 will >keep working on PHP7 without any changes. Most of the "modern" codebases >probably will though. But there is a vociferous group who want to change the language in a revolutionary way instead of an evolutionary way. They want to drop weak typing and replace it with strict typing, they want to replace a lot of function names with something "more consistent", and they want PHP to have a "purer" OO model so that instead of "string = strtoupper($string)" you must use "$string->toUpper". These revolutionaries want PHP 7 to be a different language, not an extension of the existing PHP 5 version. -- Tony Marston --- ## #82253 — Matteo Beccati — 2015-02-09T09:54:26+00:00 URL: https://externals.io/message/82095#82253 · In reply to: #82252 > But there is a vociferous group who want to change the language in a > revolutionary way instead of an evolutionary way. They want to drop weak > typing and replace it with strict typing, they want to replace a lot of > function names with something "more consistent", and they want PHP to > have a "purer" OO model so that instead of "string = > strtoupper($string)" you must use "$string->toUpper". These > revolutionaries want PHP 7 to be a different language, not an extension > of the existing PHP 5 version. I don't see any such RFC for PHP7. So it's probably worth if we avoid complaining about something that's not being proposed and certainly not going to happen. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #82254 — Tony Marston — 2015-02-09T10:07:34+00:00 URL: https://externals.io/message/82095#82254 · In reply to: #82253 "Matteo Beccati" wrote in message news:54D883D2.5020009@beccati.com... > > > > […] > >I don't see any such RFC for PHP7. So it's probably worth if we avoid >complaining about something that's not being proposed and certainly not >going to happen. There may not be an actual RFC for any of these *YET*, but the revolutionaries are still out there, plotting and scheming in their dark corners. They will be the ones who leap on an innocent-sounding feature and silently convert it to something more insidious. Just look at how "type hinting" has been turned into "type enforcement" as an example. -- Tony Marston --- ## #82255 — Matteo Beccati — 2015-02-09T10:16:26+00:00 URL: https://externals.io/message/82095#82255 · In reply to: #82254 > There may not be an actual RFC for any of these *YET*, but the > revolutionaries are still out there, plotting and scheming in their dark > corners. They will be the ones who leap on an innocent-sounding feature > and silently convert it to something more insidious. Just look at how > "type hinting" has been turned into "type enforcement" as an example. Only if you're willing to use it. But with the current proposal, no 3rd party library developer can actually force you to use strict typing if you don't want to. What's insidious about it? That's the reason I voted "yes", even though I dislike the idea of strict scalar type hinting in PHP. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #82258 — Rowan Collins — 2015-02-09T10:40:13+00:00 URL: https://externals.io/message/82095#82258 · In reply to: #82209 Lester Caine wrote on 09/02/2015 01:31: > > > […] > Something*I* have been asking for for the last few years IS a better > 'style guide' ... There are a growing number of 'styles' and the current > debate is to allow even more! Just about every framework has a different > style of handling database abstraction, and that seems to change every > major version as well. All of my own code is based around ADOdb, but now > it seems THAT is not an acceptable style of code these days. This is true of pretty much every language under the sun, and isn't really relevant to the internals of the language. It's about finding books, websites, libraries, and experts who you trust and agree with on matters of opinion and prediction. PHP-FIG is working on standardising some aspects, but others will always be a matter of fashion and taste. Regards, -- Rowan Collins [IMSoP] --- ## #82263 — Rowan Collins — 2015-02-09T10:50:49+00:00 URL: https://externals.io/message/82095#82263 · In reply to: #82254 Tony Marston wrote on 09/02/2015 10:07: > There may not be an actual RFC for any of these *YET*, but the > revolutionaries are still out there, plotting and scheming in their > dark corners. They will be the ones who leap on an innocent-sounding > feature and silently convert it to something more insidious. Seriously!? PHP's decision process is wide open to scrutiny, and controversial features are nearly always loudly debated, to the point of holding up progress at times. The idea that someone could somehow slip a critically breaking change into the language *insidiously* is utterly ridiculous, and an insult to all the people who work hard honestly trying to make the language better for everyone. > Just look at how "type hinting" has been turned into "type > enforcement" as an example. OK, I'll look; I'll look at how many hours of debating it's generated, and how many different points of view have been put in, and how hard Andrea has worked to make the current proposal a compromise which breaks the deadlock. This is so completely the opposite of "revolutionaries plotting in dark corners" that the comparison is laughable. Keep your conspiracy theories for Youtube, and concern yourself with the real proposals that are actually happening, all of which are evolutions of the language. Regards, -- Rowan Collins [IMSoP]