Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  106995
September 12, 2019 18:06 oludonsexy@gmail.com (Olumide Samson)
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 <mike@newclarity.net> wrote:

> > On Sep 12, 2019, at 10:37 AM, Lynn <kjarli@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepeeler@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 > >
  106997
September 12, 2019 18:09 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 2:07 PM Olumide Samson <oludonsexy@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 <mike@newclarity.net> wrote: > > > > On Sep 12, 2019, at 10:37 AM, Lynn <kjarli@gmail.com> wrote: > > > > > > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepeeler@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 chasepeeler@gmail.com
  107024
September 12, 2019 21:46 mike@newclarity.net (Mike Schinkel)
On Sep 12, 2019, at 11:06 AM, Olumide Samson <oludonsexy@gmail.com> wrote:
> I think they could switch to using null instead, or perhaps get something else to differentiate what they have initialized or not,
Perhaps, but switching the code requires finding the right people to do the work and then funding the changes. A lot of WordPress code marginally maintained is at best — especially WordPress sites. That differs from what it sounds like are the practices of those who are arguing for enforced strictness here on this list.
> 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..
Hopefully my words did not imply that. I think I instead stated that they would likely never upgrade.
> 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"?
It is absolutely an assumption. Based on my experience. But YMMV. That said, I can give you stats for how many WordPress plugins there are on the WordPress repository, around 68,000. And in my experience a sizable percentage of them would break with these changes. Whether or not the PHP community cares about breaking a large number of WordPress sites or not is up to those of you who get to vote. I just commented to include this perspective since I have not seen anyone else mention WordPress on the list recently.
> It's up to them, PHP 7 is still available and will always be available for them to use...
Yes. But of course, at some point PHP 7 will no longer be officially supported. At which point PHP7 users will be forced to decide between support and choosing a support direction for their future. And again, #jmtcw -Mike