Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  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