Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  106994
September 12, 2019 17:58 mike@newclarity.net (Mike Schinkel)
> 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. 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. 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. #jmtcw -Mike
  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
  106998
September 12, 2019 18:09 kjarli@gmail.com (Lynn)
On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mike@newclarity.net> wrote:

> > > 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. > > The bug is not that you initialized the variable, it's that you initialized
it with a different value: https://3v4l.org/8mB8B ``` var_dump(isset($a)); $a = null; var_dump(isset($a)); // gives bool(false) bool(false) ``` Whenever one of these errors will occur, you can initialize either the array key or variable with null and it will work again without changing behavior. If anything, Wordpress shouldn't be an argument to not improve PHP, though I think it's important to consider the impact of a change, including for the Wordpress community. However, I think most people agree that the quality of Wordpress code and Plugins is highly debatable. I don't like the idea of not being able to progress because Wordpress users won't upgrade PHP. Regards, Lynn van der Berg
  107000
September 12, 2019 18:13 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 7:10 PM Lynn <kjarli@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mike@newclarity.net> wrote: > > > > > > > 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. > > > > > The bug is not that you initialized the variable, it's that you initialized > it with a different value: https://3v4l.org/8mB8B > ``` > var_dump(isset($a)); > $a = null; > var_dump(isset($a)); > > // gives > bool(false) > bool(false) > ``` > > Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's important to consider the impact of a change, > including for the Wordpress community. However, I think most people agree > that the quality of Wordpress code and Plugins is highly debatable. I don't > like the idea of not being able to progress because Wordpress users won't > upgrade PHP. > > even without a statistics to back the word is plainfully meaningless...
I guess we tend to use the word "HUGELY","NEVER","EVER","COMPANY", etc wrongly on the list just to prove some points. And, we're better off than that IMO...
> Regards, > Lynn van der Berg >
  107001
September 12, 2019 18:14 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 2:10 PM Lynn <kjarli@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mike@newclarity.net> wrote: > > > > > > > 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. > > > > > The bug is not that you initialized the variable, it's that you initialized > it with a different value: https://3v4l.org/8mB8B > ``` > var_dump(isset($a)); > $a = null; > var_dump(isset($a)); > > // gives > bool(false) > bool(false) > ``` > > Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's important to consider the impact of a change, > including for the Wordpress community. However, I think most people agree > that the quality of Wordpress code and Plugins is highly debatable. I don't > like the idea of not being able to progress because Wordpress users won't > upgrade PHP. > > It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress decides to take their time supporting PHP 8, wordpress users
won't have any option but to wait on upgrading.
> Regards, > Lynn van der Berg >
-- Chase Peeler chasepeeler@gmail.com
  107029
September 12, 2019 22:06 mike@newclarity.net (Mike Schinkel)
> It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress decides to take their time supporting PHP 8, wordpress users won't have any option but to wait on upgrading.
To be clear, WordPress core upgrading to support PHP won't be a big issue. And WordPress core code has actually improved significantly in recent years. Upgrading the ~68,000 open source plugins available on wordpress.org <http://wordpress.org/>, thousands of commercial plugins, and and an untold number of custom-developed bespoke plugins and custom themes is where the concern lies. -Mike
> On Sep 12, 2019, at 11:14 AM, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 2:10 PM Lynn <kjarli@gmail.com <mailto:kjarli@gmail.com>> wrote: > On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mike@newclarity.net <mailto:mike@newclarity.net>> wrote: > > > > > > > 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. > > > > > The bug is not that you initialized the variable, it's that you initialized > it with a different value: https://3v4l.org/8mB8B <https://3v4l.org/8mB8B> > ``` > var_dump(isset($a)); > $a = null; > var_dump(isset($a)); > > // gives > bool(false) > bool(false) > ``` > > Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's important to consider the impact of a change, > including for the Wordpress community. However, I think most people agree > that the quality of Wordpress code and Plugins is highly debatable. I don't > like the idea of not being able to progress because Wordpress users won't > upgrade PHP. > > It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress decides to take their time supporting PHP 8, wordpress users won't have any option but to wait on upgrading. > > Regards, > Lynn van der Berg > > > -- > Chase Peeler > chasepeeler@gmail.com <mailto:chasepeeler@gmail.com>
  107052
September 13, 2019 08:11 robert@korulczyk.pl (Robert Korulczyk)
> Upgrading the ~68,000 open source plugins available on wordpress.org <http://wordpress.org/>, thousands of commercial plugins, and and an untold number of custom-developed bespoke plugins and custom themes is where the concern lies.
Many of these are ticking bombs - unmaintained extensions with possible security issues. Right now the biggest problem of WordPress ecosystem is quality of community extensions and themes. Cutting of all old and unmaintained extensions may be not that bad... Regards, Robert Korulczyk
  107060
September 13, 2019 08:52 mike@newclarity.net (Mike Schinkel)
> Many of these are ticking bombs - unmaintained extensions with possible security issues.
Totally agree.
> Right now the biggest problem of WordPress ecosystem is quality of community extensions and themes.
Being intimately involved in the WordPress ecosystem, I do not know If it is the *biggest* problem. But I digress...
> Cutting of all old and unmaintained extensions may be not that bad...
It depends on who you ask if it is bad or not. I think that many on this list would think it is a good thing. OTOH, I think many people who have working websites that currently use one of these plugins and who do not have developers on staff would think it is a very bad thing. Especially if such a change could cost them a significant unplanned amount of money and hassle to resolve. Which brings up an important point. There is a big difference between the plugins in the WordPress.org <http://wordpress.org/> repo that might have security issues I think the WordPress Core team would be open to sunsetting any plugins that are objectively found to have security issues, or even major PHP compatibilities. OTOH, given that WordPress is over 1/3rd of the web that means many of these plugins are active on working sites, sites where their web host might encourage them to upgrade to PHP8 when PHP 7 is no longer supported. It is those people who are likely to be most negatively affected, and the vast majority of them will never have hired a developer in their life let alone understand why a handful of people decided to "break their site" without them having any say in the matter. #fwiw -Mike P.S. Again, I want to clarify I am not saying what the PHP core team should do. I am simply relaying what I think the ramifications are likely to be — based upon my experience with WordPress since 2010 and PHP since 2008 — if breaking changes are introduced into PHP 8. It is up to the voting members to actually decide what will happen.
> On Sep 13, 2019, at 1:11 AM, Robert Korulczyk <robert@korulczyk.pl> wrote: > >> Upgrading the ~68,000 open source plugins available on wordpress.org <http://wordpress.org/>, thousands of commercial plugins, and and an untold number of custom-developed bespoke plugins and custom themes is where the concern lies. > > Many of these are ticking bombs - unmaintained extensions with possible security issues. Right now the biggest problem of WordPress ecosystem is > quality of community extensions and themes. Cutting of all old and unmaintained extensions may be not that bad... > > > Regards, > Robert Korulczyk
  107061
September 13, 2019 08:59 oludonsexy@gmail.com (Olumide Samson)
I'm thinking this thread is receiving much attention than really required.

Irrespective of the left and right argument, I think everyone wants a
better language, the leftist are just arguing on a very lazy fact, not that
they don't see anything bad in their wrong argument they are all just
trying to hide behind "We know it is bad or can be devastating, let's just
leave it as it is and hope nobody ever have reasons to clean it since it is
still working" but me and those rightist are all like, this is wrong let's
save billions of codes that could still be added to this buggy behavior
than leaving it and hoping it would be one of the best dynamism people want
from PHP.

How does bug translate to dynamism?

Why were there notices if something wasn't wrong somewhere with the
behavior?

If I'm to argue as php-src(being human), I would never allow those leftist
to use me to write code again coz it is highly straining to pretend to know
what an undefined variable meant( to be an int or string, or even an
object) or even if it was a typo.

We are straining the language performance even more by making it guess what
the undefined variable would have been.

Even a string would still go up as integer the moment you add ++($i++) to
it.

Why don't you people see it is safe and would be in everyone's best
interests if we could clean this garbage behavior once and for all to live
peacefully, and possibly reduce the amount of baggage behavior lying around
in millions of codes out there, coz the counts increase every single day
because everyone thinks it is the right behavior yet their error_log keep
on getting notices?


Zeev said the RFC was never meant to deprecate things and as such the
voting would eventually not pass on to implementation even if it was
accepted -

"why then do you vote no on the RFC if it was never a valid vote to count?"

I think voting on the RFC validates the RFC for all you've voted it for
which means it's a valid way to deprecate features, else all formerly
deprecated features can be reverted since they are invalidated by the
current situation(or eye opening statement you just made).

I think we all need to see from the right spot how many people and code we
would save if this garbage were reported as Warning or error as early as
possible than waiting for never yet still giving me notice in my error_log
everytime PHP hit an undefined variable.

One thing some people are forgetting is that this is an open source
community and people(myself included) coming here to pull, push, commit,
test, manage and even join the mailing list are not getting paid by anyone
to do so(there might be an exception), and being an open source project we
all need to agree to disagree no one has any authority over anyone.

If there's been some laid out rules about some chairmen and the authorities
they posses to always swing things in their favor, I'm very sure this
project would have been dead on arrival( while there are so many projects
wanting attention), since a open source project needs help from
contributors I think we all need to think properly about rules or
guidelines that might hurt the project's contribution.

I don't pray to see PHP 9 timelines not posted by anyone(coz there's no one
around to do so) or even php-src to be one of those languages where their
contribution reduced drastically based on some people's bad influence
affecting the other contributors.

Let's argue rightly and expect other people to not agree with us, that's
the default.

Thanks,
Samson(noobshow)

On Fri, Sep 13, 2019, 9:11 AM Robert Korulczyk <robert@korulczyk.pl> wrote:

> > Upgrading the ~68,000 open source plugins available on wordpress.org < > http://wordpress.org/>, thousands of commercial plugins, and and an > untold number of custom-developed bespoke plugins and custom themes is > where the concern lies. > > Many of these are ticking bombs - unmaintained extensions with possible > security issues. Right now the biggest problem of WordPress ecosystem is > quality of community extensions and themes. Cutting of all old and > unmaintained extensions may be not that bad... > > > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107069
September 13, 2019 09:29 zeev@php.net (Zeev Suraski)
On Fri, Sep 13, 2019 at 11:59 AM Olumide Samson <oludonsexy@gmail.com>
wrote:

> "We know it is bad or can be devastating
Actually, that's not at all what we're saying. I think that doing something like @$foo++ is absolutely fine. Many others on this (and related) threads think so too. I find all the 'improvements' with littered questionmarks to be a giant step backwards.
> Why were there notices if something wasn't wrong somewhere with the > behavior? >
We've been through that. You may want to take a look again at the definition of what a notice is. Zeev said the RFC was never meant to deprecate things and as such the
> voting would eventually not pass on to implementation even if it was > accepted - > > "why then do you vote no on the RFC if it was never a valid vote to count?" >
Which is precisely why I didn't vote on that particular part of the RFC so far. That said - I am considering voting a 'keep notice' on it, and I'll briefly explain why. The choice between moving to a warning or keeping a notice is completely legit, and moving it to a warning may even a good idea (mainly due to error reporting defaults, even though a notice is technically more appropriate; main worry is that it might constitute a reason for others in the future to say it's no longer legitimate, and therefore it's no big deal to deprecate it). The part of moving to an error exception is not - as it is a radical change in functionality (and not a simple 'reclassification of errors'), aka deprecation. If I do choose to vote to one of the other two options - it should be taken in the context of choosing between the two valid options, and not as any sort of validation on the invalid one. Zeev
  107004
September 12, 2019 18:30 andreas@dqxtech.net (Andreas Hennings)
Indeed, for the case of local variables that were undefined before,
this can usually be fixed in a straightforward way by initializing to
NULL.
The goal here is to get rid of the error or notice while preserving
the original behavior (even if it was buggy).

This is IF this is your own custom code, or you have a strategy for
maintaining patches on 3rd party code. (which you probably should).

Another problem which has not been talked about much is code like
this, which I have seen in multiple legacy code bases for Drupal 7
projects. Code like this is not considered good practice in Drupal 7,
but it does exist.

  $element['field_category'][LANGUAGE_NONE][0]['#entity']->field_author_label['en'][0]['value'];

This is crying for "trying to access property of non-object". Because
the values in $element were usually created "elsewhere", and who knows
if the value at that position is an object?

Even worse: This might go unnoticed 99% of the time, but in a specific
edge case the value might not be initialized and the website would
crash with error in PHP8.

The "minimal fix" to preserve behavior 1:1 is to call if (isset()) or
if (!empty()) on the whole thing before every such construct, even if
at the moment you are not aware of cases where it might fail. In the
"else" case, you do whatever would have happened before if the value
was NULL.

On Thu, 12 Sep 2019 at 20:10, Lynn <kjarli@gmail.com> wrote:
> > On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mike@newclarity.net> wrote: > > > > > > > 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. > > > > > The bug is not that you initialized the variable, it's that you initialized > it with a different value: https://3v4l.org/8mB8B > ``` > var_dump(isset($a)); > $a = null; > var_dump(isset($a)); > > // gives > bool(false) > bool(false) > ``` > > Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's important to consider the impact of a change, > including for the Wordpress community. However, I think most people agree > that the quality of Wordpress code and Plugins is highly debatable. I don't > like the idea of not being able to progress because Wordpress users won't > upgrade PHP. > > Regards, > Lynn van der Berg
  107019
September 12, 2019 20:57 phpmailinglists@gmail.com (Peter Bowyer)
On Thu, 12 Sep 2019 at 19:10, Lynn <kjarli@gmail.com> wrote:

> Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's important to consider the impact of a change, > including for the Wordpress community. However, I think most people agree > that the quality of Wordpress code and Plugins is highly debatable. I don't > like the idea of not being able to progress because Wordpress users won't > upgrade PHP. >
This raises an interesting, tangential point. Who is PHP for? One can argue that WordPress, with it powering 34% of the web (source: wordpress.org) represents more than 50% of PHP users, and therefore aligning the language to how they use it would be sensible, as they are the majority of users. PHP and WordPress have had a symbiotic relationship, the success of one increasing the success of the other. Those who wish PHP was more advanced and different (and I count myself amongst them) do well to remember that PHP has become extraordinarily successful in spite of the flaws now perceived. It's a good language that fills a niche even server-side JavaScript hasn't usurped. There is no shame in a language staying true to its roots, plateauing and eventually dying a death (cf Perl 5). I don't want that, but it's a valid route. And the communities that use PHP in a way many on this list look down on will be thankful to continue to have a language they can use, can hack with, and get stuff done. Even if there's a few extra bugs. The rest of us, meanwhile, have the opportunity to use a programming language that's closer to whatever we feel is a "proper" language (a vibe I pick up in the "they look down on us" and "I'd rather PHP was more like X" messages). If you're going to have to justify upgrading your code, why not propose a rewrite in another language? One can sell it on the fact it won't have the flaws regularly brought up on this list - like warnings instead of exceptions, or two opening tags. Or, despite the fuss on-list, do those who decide how the next project will be written/the current one rewritten, not care to the same extent, and other factors will influence their choice? Personally I cannot wait for new features to be added, but feel our heritage is as important as the future. Jordi expresses my feelings, and I quote him: Breaking BC here does not seem to bring much. If there are cases where
> enforcing strictness might allow better JIT for example, then I could > see the case being made. But simply turning working code into fatally > failing code isn't progress. [...] So what do we gain exactly? >
Peter
  107023
September 12, 2019 21:34 kjarli@gmail.com (Lynn)
On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer <phpmailinglists@gmail.com>
wrote:

> > One can argue that WordPress, with it powering 34% of the web (source: > wordpress.org) represents more than 50% of PHP users, and therefore > aligning the language to how they use it would be sensible, as they are the > majority of users. PHP and WordPress have had a symbiotic relationship, the > success of one increasing the success of the other. >
How many of those are actually developers? Because the way I understand this numbers, "powering the web", that doesn't mean 34% are also developers. It wouldn't surprise me if a big portion of these applications could've also be a system written in another language, deployed, plugins installed, added some themes and done, no PHP knowledge required. Regards, Lynn van der Berg
  107030
September 12, 2019 22:09 zeev@php.net (Zeev Suraski)
On Fri, Sep 13, 2019 at 12:35 AM Lynn <kjarli@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer <phpmailinglists@gmail.com> > wrote: > > > > > One can argue that WordPress, with it powering 34% of the web (source: > > wordpress.org) represents more than 50% of PHP users, and therefore > > aligning the language to how they use it would be sensible, as they are > the > > majority of users. PHP and WordPress have had a symbiotic relationship, > the > > success of one increasing the success of the other. > > > > How many of those are actually developers? Because the way I understand > this numbers, "powering the web", that doesn't mean 34% are also > developers. It wouldn't surprise me if a big portion of these applications > could've also be a system written in another language, deployed, plugins > installed, added some themes and done, no PHP knowledge required. >
Many are. The WP developer ecosystem footprint is at the same order of magnitude as (and in some geographics larger than) that of 'generic' PHP - in terms of conferences and conference sizes, usergroups, available jobs, etc. I don't think any of us can pull numbers off of our sleeves - but the vast majority of folks who deploy WordPress sites that I bumped into also deal with at least some custom PHP code - and are responsible for the deployment whether they wrote it or not. It's true that there are many agencies and freelancers that do a lot more than one site. But it's also true that the WordPress numbers are enormous even if we cut them down by a factor of 10 (which I believe would be big exaggeration) And of course, the can be said about PHP apps in general - many developers produce a lot more than just one site. So while there's no 1:1 correlation between the number of sites and the number of developers, it's true for both WP and generic PHP (perhaps in slightly different scales). And of course #2 - we're not only talking about WordPress - non-WP developers will be affected by this as well. Zeev
  107031
September 12, 2019 22:16 mike@newclarity.net (Mike Schinkel)
> How many of those are actually developers? Because the way I understand this numbers, "powering the web", that doesn't mean 34% are also developers. It wouldn't surprise me if a big portion of these applications could've also be a system written in another language, deployed, plugins installed, added some themes and done, no PHP knowledge required.
Most WordPress users are *not* programmers. Which is why introducing breaking changes to PHP will potentially affect them so negatively; because they have no programmers on staff nor any skill to fix the problem. Which means they will have to hire expensive programmers — like me!!! — to fix a problem that from their perspective they do not understand nor will even recognize a benefit when the code is "fixed." Again, I am just presenting this perspective on this list. Those who vote on this list will decide if breaking WordPress end-user's site bothers them or not. -Mike P.S. I am writing during a break at a WordPress conference, ironically.
  107033
September 12, 2019 23:21 krakjoe@gmail.com (Joe Watkins)
Zeev,

I'm going to keep this really short and simple ...

You don't have the authority to make unilateral decisions for PHP,.

Nothing you are saying is going to have any effect, the people who actually
work on the language will merge whatever is voted in.

Cheers

On Fri, 13 Sep 2019, 00:17 Mike Schinkel, <mike@newclarity.net> wrote:

> > How many of those are actually developers? Because the way I understand > this numbers, "powering the web", that doesn't mean 34% are also > developers. It wouldn't surprise me if a big portion of these applications > could've also be a system written in another language, deployed, plugins > installed, added some themes and done, no PHP knowledge required. > > Most WordPress users are *not* programmers. > > Which is why introducing breaking changes to PHP will potentially affect > them so negatively; because they have no programmers on staff nor any skill > to fix the problem. Which means they will have to hire expensive > programmers — like me!!! — to fix a problem that from their perspective > they do not understand nor will even recognize a benefit when the code is > "fixed." > > Again, I am just presenting this perspective on this list. Those who vote > on this list will decide if breaking WordPress end-user's site bothers them > or not. > > > -Mike > > P.S. I am writing during a break at a WordPress conference, ironically. > >
  107035
September 12, 2019 23:45 zeev@zend.com (Zeev Suraski)
On 13 Sep 2019, at 2:21, Joe Watkins <krakjoe@gmail.com<mailto:krakjoe@gmail.com>> wrote:

Zeev,

I'm going to keep this really short and simple ...

I'll do the same.

You don't have the authority to make unilateral decisions for PHP,.

Neither does anybody else on this list.  Not even a plurality or a majority of folks on this list has the authority to apply the RFC process to something it was clearly not designed to handle.

Nothing you are saying is going to have any effect, the people who actually
work on the language will merge whatever is voted in.

Without getting to the technicalities, simply put, no.

Zeev
  107036
September 12, 2019 23:50 krakjoe@gmail.com (Joe Watkins)
Zeev,

> Without getting to the technicalities, simply put, no.
I'm not sure what you intend to do to stop it. Once again, I remind you that you don't have the authority that your behaviour communicates you have, at all. I wasn't starting a conversation, I was communicating facts, and I'm finished communicating with you. Cheers Joe On Fri, 13 Sep 2019 at 01:45, Zeev Suraski <zeev@zend.com> wrote:
> > > On 13 Sep 2019, at 2:21, Joe Watkins <krakjoe@gmail.com> wrote: > > Zeev, > > I'm going to keep this really short and simple ... > > > I'll do the same. > > You don't have the authority to make unilateral decisions for PHP,. > > > Neither does anybody else on this list. Not even a plurality or a > majority of folks on this list has the authority to apply the RFC process > to something it was clearly not designed to handle. > > Nothing you are saying is going to have any effect, the people who actually > work on the language will merge whatever is voted in. > > > Without getting to the technicalities, simply put, no. > > Zeev > >
  107037
September 12, 2019 23:56 vsuraski@gmail.com (Zeev Suraski)
> On 13 Sep 2019, at 2:50, Joe Watkins <krakjoe@gmail.com> wrote: > > Zeev, > > > Without getting to the technicalities, simply put, no. > > I'm not sure what you intend to do to stop it.
I sincerely hope reason will prevail and we won't have to find out (as I was hoping this part of the RFC won't be put up for a vote so that we wouldn't be in this mess to begin with). I am not looking forward to it - but we will not be depreciating fundamental language functionality regardless of the results of this or any other RFC - as RFCs have no mandate to do that. That is a statement of fact. Cheers, Zeev
  107054
September 13, 2019 08:19 brendt@stitcher.io (Brent)
Hello Zeev

Would you mind sharing with us why you specifically would be able to single handedly decide what gets merged into PHP and what not?

Kind regards
Brent
On 13 Sep 2019, 01:56 +0200, Zeev Suraski <vsuraski@gmail.com>, wrote:
> > > On 13 Sep 2019, at 2:50, Joe Watkins <krakjoe@gmail.com> wrote: > > > > Zeev, > > > > > Without getting to the technicalities, simply put, no. > > > > I'm not sure what you intend to do to stop it. > > I sincerely hope reason will prevail and we won't have to find out (as I was hoping this part of the RFC won't be put up for a vote so that we wouldn't be in this mess to begin with). I am not looking forward to it - but we will not be depreciating fundamental language functionality regardless of the results of this or any other RFC - as RFCs have no mandate to do that. That is a statement of fact. > > Cheers, > > Zeev
  107048
September 13, 2019 07:41 lester@lsces.uk (Lester Caine)
On 12/09/2019 23:16, Mike Schinkel wrote:
>> How many of those are actually developers? Because the way I understand this numbers, "powering the web", that doesn't mean 34% are also developers. It wouldn't surprise me if a big portion of these applications could've also be a system written in another language, deployed, plugins installed, added some themes and done, no PHP knowledge required. > Most WordPress users are*not* programmers. > > Which is why introducing breaking changes to PHP will potentially affect them so negatively; because they have no programmers on staff nor any skill to fix the problem. Which means they will have to hire expensive programmers — like me!!! — to fix a problem that from their perspective they do not understand nor will even recognize a benefit when the code is "fixed." > > Again, I am just presenting this perspective on this list. Those who vote on this list will decide if breaking WordPress end-user's site bothers them or not.
Something which does not help here is the way WordPress enforces upgrades that may not be compatible with all elements of the themes that the user currently has active. I AM a programmer rather than a web designer and am having trouble keeping WordPress sites stable. To that end I have decided simply to freeze at PHP7.2 for various reasons but WordPress is now complaining that the version of PHP is out of date. One just can't win ... some of the WordPress sites themes will not even work with PHP7 (or WP5) at all. So we *DO* need an LTS version of PHP that will run perfectly functional websites for the next ten years while others create the next replacement for the likes of WordPress by moving framework functionality inside PHP ... Much of the discussion on new features cut across the ways frameworks already handle that functionality ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
  107051
September 13, 2019 08:10 cschneid@cschneid.com (Christian Schneider)
Am 13.09.2019 um 09:41 schrieb Lester Caine <lester@lsces.uk>:
> On 12/09/2019 23:16, Mike Schinkel wrote: >> Those who vote on this list will decide if breaking WordPress end-user's site bothers them or not.
That's something too few people on this list seem to be aware of: Breaking other people's perfectly functional code because you believe in a different coding style is not something which should be done easily.
> So we *DO* need an LTS version of PHP that will run perfectly functional websites for the next ten years while others create the next replacement for the likes of WordPress by moving framework functionality inside PHP ...
I agree! Which means there will be additional burden on the PHP core developers as there will be another version to back port security fixes to for a long time. Also not a decision to be made lightly. While I do like democracy I also agree with Zeev that it is too easy for people to vote yes on a breaking change even if they didn't think it through. So if you voted yes for any change of a notice/warning to an exception (which will break things) please reconsider! Is it really worth it? And if you really think so, could we make it opt-in? Or at least globally opt-out-able? - Chris
  107053
September 13, 2019 08:18 kontakt@beberlei.de (Benjamin Eberlei)
On Fri, Sep 13, 2019 at 10:10 AM Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 13.09.2019 um 09:41 schrieb Lester Caine <lester@lsces.uk>: > > On 12/09/2019 23:16, Mike Schinkel wrote: > >> Those who vote on this list will decide if breaking WordPress > end-user's site bothers them or not. > > That's something too few people on this list seem to be aware of: > Breaking other people's perfectly functional code because you believe in a > different coding style is not something which should be done easily. > > > So we *DO* need an LTS version of PHP that will run perfectly functional > websites for the next ten years while others create the next replacement > for the likes of WordPress by moving framework functionality inside PHP ... > > I agree! > Which means there will be additional burden on the PHP core developers as > there will be another version to back port security fixes to for a long > time. Also not a decision to be made lightly. >
I would think that this is exactly what a company like Zend would charge their customers for. Microsoft is doing it for free for 5.6, I imagine for their bigger Azure customres here: https://github.com/microsoft/php-src LTS versions should not be the responsibility of the core developers, they are the responsibile of a legal entity with financial means that either directly sponsors the OSS project (Ubuntu) or is downstream of the project (RedHat). PHP is entirely a community project of volunteers that is already hanging by a thread given the workload.
> While I do like democracy I also agree with Zeev that it is too easy for > people to vote yes on a breaking change even if they didn't think it > through. > > So if you voted yes for any change of a notice/warning to an exception > (which will break things) please reconsider! > Is it really worth it? And if you really think so, could we make it > opt-in? Or at least globally opt-out-able? > > - Chris > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107055
September 13, 2019 08:28 markyr@gmail.com (Mark Randall)
On 13/09/2019 09:10, Christian Schneider wrote:
> Is it really worth it?
It's absolutely worth it. Stopping execution flow at erroneous or ambiguous statements is an essential part of secure, reliable programming. A notice or warning offers no protection at all. Unless you've taken some very specific steps, your program will continue operating as if they never happened, even if that notice or warning was clearly a high probability of being a bug.
> And if you really think so, could we make it opt-in?
People should not have to opt in to common sense defaults. If I sell you a car, you shouldn't have to opt in to having the bolts on your tyres fastened on tight enough that the wheels don't fall off the moment you hit motorway speed.
> Or at least globally opt-out-able?
Let's not. Never again should an option like enable_short_tags exist. If you want a per-file opt out, the notion of declare(sloppy=1); Has already been jokingly proposed, and I would personally have no problem with it if people want to opt-in to less reliable enforcement... but once again, I stress that the defaults should always be best-practices. -- Mark Randall
  107064
September 13, 2019 09:10 php-lists@koalephant.com (Stephen Reay)
> On 13 Sep 2019, at 15:28, Mark Randall <markyr@gmail.com> wrote: > > the notion of > > declare(sloppy=1); > > Has already been jokingly proposed,
Who ever said it was a joke proposal? :-P
  107028
September 12, 2019 22:02 mike@newclarity.net (Mike Schinkel)
> Whenever one of these errors will occur, you can initialize either the array key or variable with null and it will work again without changing behavior.
Whatever the case, changing warnings to errors would require fixing working code. And for many people, that would requiring investing lots of money.
> However, I think most people agree that the quality of Wordpress code and Plugins is highly debatable.
That is probably very true, but it is orthogonal to whether or not certain potential changes in PHP would cause expense changes to be implemented in order for WordPress users to upgrade to an incompatible PHP8.
> If anything, Wordpress shouldn't be an argument to not improve PHP, though I think it's important to consider the impact of a change, including for the Wordpress community. > I don't like the idea of not being able to progress because Wordpress users won't upgrade PHP.
I am not making that argument. I am simply pointing out that the changes being considered will almost certainly break a large percentage of WordPress sites and fixing those site will likely be very costly for site owners. So it is up to those who have a vote on the future of PHP to decide if a large number of broken WordPress matters to them or not. I am just a messenger. -Mike