I think it would do this list more good than not, if we talk or assume about some people who will ever or never upgrade... Seriously? How do you know if they would never or ever upgrade, you can only and should probably speak for yourself...
If they want more customers(translating to revenue), they can upgrade and if they don't it's all up to them... On Thu, Sep 12, 2019 at 6:59 PM Mike Schinkel <m...@newclarity.net> wrote: > > On Sep 12, 2019, at 10:37 AM, Lynn <kja...@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepee...@gmail.com> > wrote: > > > >> There are valid reasons for not always initializing variables or array > >> keys. It might be a bad > >> reason in your opinion, but others view it as perfectly acceptable. > >> > > > > I recently had to fix a bug where a variable was renamed, caused a merge > > conflict and resulted in months long of changing a business process with > a > > subtle bug, as null was not the intended initialized value. Whether or > not > > people should initialize variables is debatable from a programming > > perspective. From a reader's perspective it's really important to have > > variables initialized with a default value, even if it's just null, to > > prevent missing certain assignment branches and avoid bugs. From my > > perspective, this should've thrown an error, so we would've fixed it the > > same day. Now PHP simply broke our business process for months. > > > > Yes, we hide notices, even in production as our logging server would die > > within a minute if we'd turn it on. Yes, this is a massive legacy code > base > > where lots of tests are lacking. Can we change this? Sure, will take > years > > though. Would we have benefited from PHP throwing an error in this case? > > Most certainly, would've saved us a lot of headache, and money. > > > > You argue that it's a fundamental language change, I -and seemingly a lot > > of others- argue that this is more of a bug fix. > > Just a few weeks ago I was refactoring some particularly horrible code > developed by previously employed developers — a code based that has a 1400 > line function and many other functions 100s of lines long, and I added some > initialization for variable and array elements prior to their use. > > Unfortunately my changes broke the code because the original developer > using isset($var) as branching criteria. After finding this bug, I > realized that this code base uses that technique frequently. I am know > from lots of experience that this is a common technical among WordPress > plugins. > I think they could switch to using null instead, or perhaps get something else to differentiate what they have initialized or not, that shouldn't stop them from using PHP, probably it will only make them not upgrade to PHP if they think their bad coding practice is the way forward and the best way to code.. If PHP8 were to change to require variables and/or array elements to be > initialized then this code base and any similar to it will be broken. > Companies with these code bases almost certainly will simply not upgrade to > PHP 8. Probably ever. > > This is merely assumptions and you can't speak for companies you don't know, what's the statistics backing these your use of "ever and never"? > BTW, prior to gaining this company as a client, the internal people felt > that the codebase needed to be completely rewritten rather than > incrementally refactored. And because rewriting would have been such a > large project they have been putting it off for several years. In their > case, we will be cleaning up the code base (although doing so will be very > costly for them.) > > And I estimate there are a large number of similar scenarios in the wild > that do not currently have plans the people or the funds to clean up their > similar code. > > It's up to them, PHP 7 is still available and will always be available for them to use... > #jmtcw > > -Mike > >
