On Thu, Sep 12, 2019 at 2:07 PM Olumide Samson <oludons...@gmail.com> wrote:
> 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.. > > Can you please stop speaking for what you think they should do? Only they can speak for what they should do. > 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... > > Yes, but, there are going to be other features in PHP 8 that won't break existing code and are beneficial. They may be forced to stick with PHP 7, but don't act like that is a perfectly acceptable option without any downsides. > > #jmtcw > > > > -Mike > > > > > -- Chase Peeler chasepee...@gmail.com
