Changing fundamental language behaviors

  106963
September 12, 2019 14:44 zeev@php.net ("Zeev Suraski")
I was really really hoping that we will avert having to dive into this and
instead go for the alternative solution that was proposed of changing
default php.ini error levels.  But since the RFC went on to a vote - we need
to make something clear.

 

The RFC process was never, ever meant to handle fundamental changes to the
language.  It was meant to deal predominantly with additions to the
language, as can be inferred from numerous parts in the phrasing.  As I
mentioned in the past - it wasn't even intended to deal with simpler
deprecations, but it appears that the cat is out of the bag on this one.
However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
of the same bag.  Using the RFC to deprecate fundamental behaviors of the
language - such as how the language deals with undefined variables - is
simply off the table.

 

You may be wondering, in that case, what processes do we have to deal with
such changes then?  The answer is simple.  We don't.  We don't have to have
them either - the fundamental language behaviors are here to stay.

Deprecating the ability to rely on the expected default value of
uninitialized variables falls squarely in that category.  

 

Reclassifying a notice to a warning is a possibility - people's code will
still run, and they'll be able to continue using these behaviors going
forward as well if they want to (perhaps with minor tweaks to error
reporting levels).  Turning a notice to an error isn't reclassifying an
error level.  It's deprecating a behavior - and we're not talking about some
esoteric extension, but a documented, well-defined, fundamental behavior of
the language for over two decades.  The fact many of you think it's horrible
does not change that.  Deprecating such fundamentals is simply outside of
the mandate of internals@, regardless of whatever majority appears to exist
in favor of it at a given time.

 

Similarly - adding typed variables - is certainly a future option.  Changing
PHP to require typed variables (without opting in) - is well outside of the
internals@ mandate.

 

For areas like that - our options are either doing nothing, or providing
opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
2nd option, but there is no 3rd.

 

Zeev
  106965
September 12, 2019 14:52 Danack@basereality.com (Dan Ackroyd)
On Thu, 12 Sep 2019 at 15:44, Zeev Suraski <zeev@php.net> wrote:
> > The RFC process was never, ever meant to handle fundamental changes to the > language.
The only appropriate response to this is "lolwat?". You keep making up rules...that don't exist. You can't expect people to suddenly stop using RFCs to change the language just because you say so. Please stop this behaviour. It's really not appropriate. sincerely Dan Ack
  106967
September 12, 2019 14:58 arvids.godjuks@gmail.com (Arvids Godjuks)
чт, 12 сент. 2019 г. в 16:53, Dan Ackroyd <Danack@basereality.com>:

> On Thu, 12 Sep 2019 at 15:44, Zeev Suraski <zeev@php.net> wrote: > > > > The RFC process was never, ever meant to handle fundamental changes to > the > > language. > > The only appropriate response to this is "lolwat?". > > You keep making up rules...that don't exist. You can't expect people > to suddenly stop using RFCs to change the language just because you > say so. > > Please stop this behaviour. It's really not appropriate. > > sincerely > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Agree and support,
but I mostly want to convey this to everyone: For once, let's not knee-jerk post reply. Let's take a day to stew on this, formulate the though and express it. I will do the same, cause I really want to knee-jerk here, but we know how that ended in recent months and issues it caused. So let's take the opportunity to voice our opinions in an orderly manner since Zeev basically opened this can of worms and I honestly do not see this going well. -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  106970
September 12, 2019 15:02 oludonsexy@gmail.com (Olumide Samson)
You first me on that reply Dan, I guess I should just say "the naysayers
are back", I can see their footprint all around.

The RFC is Request for Comment on any changes, is there an explicit or
implicit mention about what kind of proposed changes can be made?

Mr/Mrs Zeev are you for PHP or against it?
I know you are one of the authors of Zend Engine, but please follow the
rules and don't make rules simply because something is going the way you
don't want it to.

That's why there's this called "vote".

On Thu, Sep 12, 2019, 3:52 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Thu, 12 Sep 2019 at 15:44, Zeev Suraski <zeev@php.net> wrote: > > > > The RFC process was never, ever meant to handle fundamental changes to > the > > language. > > The only appropriate response to this is "lolwat?". > > You keep making up rules...that don't exist. You can't expect people > to suddenly stop using RFCs to change the language just because you > say so. > > Please stop this behaviour. It's really not appropriate. > > sincerely > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  106974
September 12, 2019 15:27 zeev@php.net ("Zeev Suraski")
> -----Original Message----- > From: Olumide Samson <oludonsexy@gmail.com> > Sent: Thursday, September 12, 2019 6:03 PM > To: Dan Ackroyd <Danack@basereality.com> > Cc: Zeev Suraski <zeev@php.net>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > The RFC is Request for Comment on any changes, is there an explicit or implicit > mention about what kind of proposed changes can be made?
While the Voting RFC was probably one of my worst creations - because it's was so laconic and lacking (although it still probably did more good for PHP than bad) - yes - there's a strong implication as to what it's meant to deal with and what it isn't meant to deal with. Here's what the Voting RFC said: "Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible" I understand this isn't written black-on-white that you can't deprecate a fundamental language behavior. But it's clear that "having to win a 2/3 vote" isn't quite the definition of "irreversible". The idea behind the 2/3 requirement (a number that I came up with) was to ensure that the motivation to undo that addition/change will likely remain very low in the years following the vote on the RFC. Why? Because once it's in - it's in. It cannot be taken out. It's irreversible. So no, a 2/3 vote does not get us the mandate to deprecate a fundamental language behavior. It's basically a reasonably high bar to add something to the language - given that we know that once we add it, we cannot take it away. Nothing more, nothing less. Zeev
  106966
September 12, 2019 14:58 ocramius@gmail.com (Marco Pivetta)
Hi Zeev,


On Thu, Sep 12, 2019 at 4:44 PM Zeev Suraski <zeev@php.net> wrote:

> I was really really hoping that we will avert having to dive into this and > instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we > need > to make something clear. > > > > The RFC process was never, ever meant to handle fundamental changes to the > language. It was meant to deal predominantly with additions to the > language, as can be inferred from numerous parts in the phrasing. As I > mentioned in the past - it wasn't even intended to deal with simpler > deprecations, but it appears that the cat is out of the bag on this one. > However, the fact the cat is out, doesn't mean we'll let a tiger waltz out > of the same bag. Using the RFC to deprecate fundamental behaviors of the > language - such as how the language deals with undefined variables - is > simply off the table. > > > > You may be wondering, in that case, what processes do we have to deal with > such changes then? The answer is simple. We don't. We don't have to have > them either - the fundamental language behaviors are here to stay. > > Deprecating the ability to rely on the expected default value of > uninitialized variables falls squarely in that category. > > > > Reclassifying a notice to a warning is a possibility - people's code will > still run, and they'll be able to continue using these behaviors going > forward as well if they want to (perhaps with minor tweaks to error > reporting levels). Turning a notice to an error isn't reclassifying an > error level. It's deprecating a behavior - and we're not talking about > some > esoteric extension, but a documented, well-defined, fundamental behavior of > the language for over two decades. The fact many of you think it's > horrible > does not change that. Deprecating such fundamentals is simply outside of > the mandate of internals@, regardless of whatever majority appears to > exist > in favor of it at a given time. > > > > Similarly - adding typed variables - is certainly a future option. > Changing > PHP to require typed variables (without opting in) - is well outside of the > internals@ mandate. > > > > For areas like that - our options are either doing nothing, or providing > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > 2nd option, but there is no 3rd. >
If you want to have an authoritative say on what the RFC process is for or not, please start a new RFC about it: your mail is just straight out inappropriate. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  106972
September 12, 2019 15:11 zeev@php.net ("Zeev Suraski")
> -----Original Message----- > From: Marco Pivetta <ocramius@gmail.com> > Sent: Thursday, September 12, 2019 5:59 PM > To: Zeev Suraski <zeev@php.net> > Cc: PHP Internals List <internals@lists.php.net> > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > If you want to have an authoritative say on what the RFC process is for or not, > please start a new RFC about it: your mail is just straight out inappropriate.
No Marco. The RFC process wasn't meant to deal with who has authoritative say any more than it was meant to deal with changing fundamental behaviors in PHP. The fact we got used to putting everything to a vote doesn't mean that it can work for anything and everything. While I realize my email is unpleasant for many to read, it's in the context of an RFC that attempts to do something that is strictly inappropriate and out of the question. Stating the fact, that the RFC process was never meant to allow this to be done, is a statement of fact. I *hate* to be in the position to be the one who has to point it out and stick to it. I know how much fire that's going to draw and I know I'd hate every second of it. But it is what it is. There are no processes to make fundamental non-opt-in language changes in PHP. There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or radically change them. We can (and I believe should) augment them with alternative, stricter opt-in behaviors. But those who dream of simply changing PHP into a stricter language step by step should understand that this is simply not going to be happen. Not now, not ever. Zeev
  106978
September 12, 2019 16:18 morganbreden@gmail.com (Morgan Breden)
> While I realize my email is unpleasant for many to read, it's in the context of an RFC that attempts to do something that is strictly
inappropriate and out of the question. Stating the fact, that the RFC process was never meant to allow this to be done, is a statement of fact. [...]
> There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or
radically change them. [...]
> But those who dream of simply changing PHP into a stricter language step by step should understand that this is simply not going to be happen. Not
now, not ever. Zeev, "strictly inappropriate and out of the question" seems like a statement of opinion to me. While I personally agree with your standpoint on changing this fundamental behavior, your response here seems out of left field. Furthermore, statements like "we do not get to deprecate or radically change them" and "this is simply not going to happen" are a wholly inappropriate response to *any* effort. I respect your vast contributions to the language and your (usually) level-headed stances on this mailing list, but you are not the grand czar of PHP and I don't believe that hard line is yours to make. Declaring such a thing reads to me like a spit in the face of everyone who contributes to the language and to the concept of a community-driven open source project to begin with. Over the past few years the movement to push PHP into more modern concepts has explosively grown in popularity and your resistance to the more rapid and drastic portions of it is understandable, if nothing else. However, using your bully pulpit to insist that things you don't like can't be done leaves a very sour taste in my mouth. If such limits exist, they should be clear and codified - not something that exists in the mind of you and whoever else only to be brought up when someone wants to breach them. On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote:
> > > > -----Original Message----- > > From: Marco Pivetta <ocramius@gmail.com> > > Sent: Thursday, September 12, 2019 5:59 PM > > To: Zeev Suraski <zeev@php.net> > > Cc: PHP Internals List <internals@lists.php.net> > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > > > If you want to have an authoritative say on what the RFC process is for > or not, > > please start a new RFC about it: your mail is just straight out > inappropriate. > > No Marco. The RFC process wasn't meant to deal with who has authoritative > say any more than it was meant to deal with changing fundamental behaviors > in PHP. The fact we got used to putting everything to a vote doesn't mean > that it can work for anything and everything. > > While I realize my email is unpleasant for many to read, it's in the > context of an RFC that attempts to do something that is strictly > inappropriate and out of the question. Stating the fact, that the RFC > process was never meant to allow this to be done, is a statement of fact. > > I *hate* to be in the position to be the one who has to point it out and > stick to it. I know how much fire that's going to draw and I know I'd hate > every second of it. But it is what it is. > > There are no processes to make fundamental non-opt-in language changes in > PHP. There won't be such processes either. These behaviors are here to > stay. We can tweak them, we can augment them - we do not get to deprecate > or radically change them. > > We can (and I believe should) augment them with alternative, stricter > opt-in behaviors. But those who dream of simply changing PHP into a > stricter language step by step should understand that this is simply not > going to be happen. Not now, not ever. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  106980
September 12, 2019 16:51 scott@paragonie.com (Scott Arciszewski)
I'd like to weigh in as a voice of reason here.

> There are no processes to make fundamental non-opt-in language changes in PHP.
This part might be reasonable.
> There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or radically change them.
This part is totally unreasonable. Let me explain: "We lack a process" opens a door. If the RFC process is inadequate to address necessary deprecations and removals, then what process *would* be adequate and appropriate? THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe contrary to Zeev about whether the RFC process is adequate and appropriate. "There won't be such processes either" shuts the just-opened door in the rudest manner possible. This doesn't lead to a productive conversation, this just ends it with Zeev's opinion being final. My thoughts: I think we should give Zeev precisely half of what he wants here: Let's discuss whether a separate process should be created for deprecations/removals... and if so, what it would look like. And then if we come up with something new, in true Internals fashion, create an RFC and vote on our new addition to the RFC process. (Even Zeev has to acknowledge that additions are fine, with 2/3 majority.) But we shouldn't accept his door-shutting terms just because he says so. Respectfully, Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote:
> > > > > -----Original Message----- > > From: Marco Pivetta <ocramius@gmail.com> > > Sent: Thursday, September 12, 2019 5:59 PM > > To: Zeev Suraski <zeev@php.net> > > Cc: PHP Internals List <internals@lists.php.net> > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > > > If you want to have an authoritative say on what the RFC process is for or not, > > please start a new RFC about it: your mail is just straight out inappropriate. > > No Marco. The RFC process wasn't meant to deal with who has authoritative say any more than it was meant to deal with changing fundamental behaviors in PHP. The fact we got used to putting everything to a vote doesn't mean that it can work for anything and everything. > > While I realize my email is unpleasant for many to read, it's in the context of an RFC that attempts to do something that is strictly inappropriate and out of the question. Stating the fact, that the RFC process was never meant to allow this to be done, is a statement of fact. > > I *hate* to be in the position to be the one who has to point it out and stick to it. I know how much fire that's going to draw and I know I'd hate every second of it. But it is what it is. > > There are no processes to make fundamental non-opt-in language changes in PHP. There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or radically change them. > > We can (and I believe should) augment them with alternative, stricter opt-in behaviors. But those who dream of simply changing PHP into a stricter language step by step should understand that this is simply not going to be happen. Not now, not ever. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  106981
September 12, 2019 16:56 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski <scott@paragonie.com>
wrote:

> I'd like to weigh in as a voice of reason here. > > > There are no processes to make fundamental non-opt-in language changes > in PHP. > > This part might be reasonable. > > > There won't be such processes either. These behaviors are here to stay. > We can tweak them, we can augment them - we do not get to deprecate or > radically change them. > > This part is totally unreasonable. > > Let me explain: > > "We lack a process" opens a door. If the RFC process is inadequate to > address necessary deprecations and removals, then what process *would* > be adequate and appropriate? > > THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe > contrary to Zeev about whether the RFC process is adequate and > appropriate. > > "There won't be such processes either" shuts the just-opened door in > the rudest manner possible. This doesn't lead to a productive > conversation, this just ends it with Zeev's opinion being final. > > My thoughts: > > I think we should give Zeev precisely half of what he wants here: > Let's discuss whether a separate process should be created for > deprecations/removals... and if so, what it would look like. And then > if we come up with something new, in true Internals fashion, create an > RFC and vote on our new addition to the RFC process. (Even Zeev has to > acknowledge that additions are fine, with 2/3 majority.) > > Don't use the term "deprecations and removals" - it's not the right term
here. There are many deprecations and removals that don't fundamentally change the language. For example, deprecating create_function() after closure support was added didn't fundamentally change the language.
> But we shouldn't accept his door-shutting terms just because he says so. > > Respectfully, > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises <https://paragonie.com> > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises > > > On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote: > > > > > > > > > -----Original Message----- > > > From: Marco Pivetta <ocramius@gmail.com> > > > Sent: Thursday, September 12, 2019 5:59 PM > > > To: Zeev Suraski <zeev@php.net> > > > Cc: PHP Internals List <internals@lists.php.net> > > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > > > > > If you want to have an authoritative say on what the RFC process is > for or not, > > > please start a new RFC about it: your mail is just straight out > inappropriate. > > > > No Marco. The RFC process wasn't meant to deal with who has > authoritative say any more than it was meant to deal with changing > fundamental behaviors in PHP. The fact we got used to putting everything > to a vote doesn't mean that it can work for anything and everything. > > > > While I realize my email is unpleasant for many to read, it's in the > context of an RFC that attempts to do something that is strictly > inappropriate and out of the question. Stating the fact, that the RFC > process was never meant to allow this to be done, is a statement of fact. > > > > I *hate* to be in the position to be the one who has to point it out and > stick to it. I know how much fire that's going to draw and I know I'd hate > every second of it. But it is what it is. > > > > There are no processes to make fundamental non-opt-in language changes > in PHP. There won't be such processes either. These behaviors are here to > stay. We can tweak them, we can augment them - we do not get to deprecate > or radically change them. > > > > We can (and I believe should) augment them with alternative, stricter > opt-in behaviors. But those who dream of simply changing PHP into a > stricter language step by step should understand that this is simply not > going to be happen. Not now, not ever. > > > > Zeev > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  106982
September 12, 2019 17:02 scott@paragonie.com (Scott Arciszewski)
Apologies for my semantic imprecision. I hope the intent of my email
remains clear.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

On Thu, Sep 12, 2019 at 12:56 PM Chase Peeler <chasepeeler@gmail.com> wrote:
> > > > On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski <scott@paragonie.com> wrote: >> >> I'd like to weigh in as a voice of reason here. >> >> > There are no processes to make fundamental non-opt-in language changes in PHP. >> >> This part might be reasonable. >> >> > There won't be such processes either. These behaviors are here to stay.. We can tweak them, we can augment them - we do not get to deprecate or radically change them. >> >> This part is totally unreasonable. >> >> Let me explain: >> >> "We lack a process" opens a door. If the RFC process is inadequate to >> address necessary deprecations and removals, then what process *would* >> be adequate and appropriate? >> >> THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe >> contrary to Zeev about whether the RFC process is adequate and >> appropriate. >> >> "There won't be such processes either" shuts the just-opened door in >> the rudest manner possible. This doesn't lead to a productive >> conversation, this just ends it with Zeev's opinion being final. >> >> My thoughts: >> >> I think we should give Zeev precisely half of what he wants here: >> Let's discuss whether a separate process should be created for >> deprecations/removals... and if so, what it would look like. And then >> if we come up with something new, in true Internals fashion, create an >> RFC and vote on our new addition to the RFC process. (Even Zeev has to >> acknowledge that additions are fine, with 2/3 majority.) >> > > Don't use the term "deprecations and removals" - it's not the right term here. There are many deprecations and removals that don't fundamentally change the language. For example, deprecating create_function() after closure support was added didn't fundamentally change the language. > >> >> But we shouldn't accept his door-shutting terms just because he says so. >> >> Respectfully, >> >> Scott Arciszewski >> Chief Development Officer >> Paragon Initiative Enterprises <https://paragonie.com> >> >> Scott Arciszewski >> Chief Development Officer >> Paragon Initiative Enterprises >> >> >> On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote: >> > >> > >> > >> > > -----Original Message----- >> > > From: Marco Pivetta <ocramius@gmail.com> >> > > Sent: Thursday, September 12, 2019 5:59 PM >> > > To: Zeev Suraski <zeev@php.net> >> > > Cc: PHP Internals List <internals@lists.php.net> >> > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors >> > > >> > > If you want to have an authoritative say on what the RFC process is for or not, >> > > please start a new RFC about it: your mail is just straight out inappropriate. >> > >> > No Marco. The RFC process wasn't meant to deal with who has authoritative say any more than it was meant to deal with changing fundamental behaviors in PHP. The fact we got used to putting everything to a vote doesn't mean that it can work for anything and everything. >> > >> > While I realize my email is unpleasant for many to read, it's in the context of an RFC that attempts to do something that is strictly inappropriate and out of the question. Stating the fact, that the RFC process was never meant to allow this to be done, is a statement of fact. >> > >> > I *hate* to be in the position to be the one who has to point it out and stick to it. I know how much fire that's going to draw and I know I'd hate every second of it. But it is what it is. >> > >> > There are no processes to make fundamental non-opt-in language changes in PHP. There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or radically change them. >> > >> > We can (and I believe should) augment them with alternative, stricter opt-in behaviors. But those who dream of simply changing PHP into a stricter language step by step should understand that this is simply not going to be happen. Not now, not ever. >> > >> > Zeev >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > -- > Chase Peeler > chasepeeler@gmail.com
  106983
September 12, 2019 17:05 matthewmatthew@gmail.com (Matthew Brown)
> > that don't fundamentally change the language
There's clearly a big disagreement about whether this is a fundamental change or not. Preventing something that the entire field of software engineering frowns upon (and that most PHP developers avoid like the plague) doesn't seem like a *fundamental* change.
  106985
September 12, 2019 17:22 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> that don't fundamentally change the language > > > There's clearly a big disagreement about whether this is a fundamental > change or not. > > Preventing something that the entire field of software engineering frowns > upon (and that most PHP developers avoid like the plague) doesn't seem like > a *fundamental* change. > > I would argue that this is exactly such a change. The flexibility of PHP
has often been touted as a feature and something that sets it apart. Whether that's good or bad is, frankly, irrelevant. 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. For 20 years people have developed code based on that feature. It was never considered an error, and often not even considered bad practice. To suddenly define it as such is the exact definition of a fundamental change to the language itself. What if Java suddenly said that all properties are suddenly private, and can only be accessed through getter/setter methods? The fact that you should make properties private and use such methods is a practice that was drilled into me from day one. Would that justify making such a change, though? -- Chase Peeler chasepeeler@gmail.com
  106986
September 12, 2019 17:33 matthewmatthew@gmail.com (Matthew Brown)
> > What if Java suddenly said that all properties are suddenly private, and > can only be accessed through getter/setter methods? >
If Java announced that the next major version was to make the change after 95% of userland developers favoured it and over 2/3rds of their internals team did, I'd think "huh ok I guess they have good reasons". For 20 years people have developed code based on that feature. It was never
> considered an error, and often not even considered bad practice
You seem to be arguing against *ever* changing something that a majority once thought was good, and fundamental to a given system. Lots of things fall into that category - restricting voting to men, segregation, etc.
>
  106989
September 12, 2019 17:41 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> What if Java suddenly said that all properties are suddenly private, and >> can only be accessed through getter/setter methods? >> > > If Java announced that the next major version was to make the change after > 95% of userland developers favoured it and over 2/3rds of their internals > team did, I'd think "huh ok I guess they have good reasons". > > For 20 years people have developed code based on that feature. It was >> never considered an error, and often not even considered bad practice > > > You seem to be arguing against *ever* changing something that a majority > once thought was good, and fundamental to a given system. Lots of things > fall into that category - restricting voting to men, segregation, etc. >
Now you're just being silly. I actually don't have a problem with fundamental language change, provided that the positives that are gained far outweigh the negatives of the BC break and there is no other way to accomplish those positives without such a BC break. There are a myriad of ways to achieve what the RFC attempts to achieve. Whether that's analysis tools, custom error handlers, detailed code reviews, etc. Nothing prevents anyone from initializing all of their variables or performing as many sanity checks on a variable before accessing it as they want to. Nothing in the RFC is required to implement other new functionality like enums, union types, variable typing, etc. I also think it's a bit of a stretch to compare something like variable initialization with things that denied people their basic human rights. -- Chase Peeler chasepeeler@gmail.com
  106992
September 12, 2019 17:57 php-lists@koalephant.com (Stephen Reay)
> On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote: > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> > wrote: > >> What if Java suddenly said that all properties are suddenly private, and >>> can only be accessed through getter/setter methods? >>> >> >> If Java announced that the next major version was to make the change after >> 95% of userland developers favoured it and over 2/3rds of their internals >> team did, I'd think "huh ok I guess they have good reasons". >> >> For 20 years people have developed code based on that feature. It was >>> never considered an error, and often not even considered bad practice >> >> >> You seem to be arguing against *ever* changing something that a majority >> once thought was good, and fundamental to a given system. Lots of things >> fall into that category - restricting voting to men, segregation, etc. >> > > Now you're just being silly. I actually don't have a problem with > fundamental language change, provided that the positives that are gained > far outweigh the negatives of the BC break and there is no other way to > accomplish those positives without such a BC break. > > There are a myriad of ways to achieve what the RFC attempts to achieve. > Whether that's analysis tools, custom error handlers, detailed code > reviews, etc. Nothing prevents anyone from initializing all of their > variables or performing as many sanity checks on a variable before > accessing it as they want to. Nothing in the RFC is required to implement > other new functionality like enums, union types, variable typing, etc. > > I also think it's a bit of a stretch to compare something like variable > initialization with things that denied people their basic human rights. > > -- > Chase Peeler > chasepeeler@gmail.com
Please, will someone arguing against making use of undefined variables a higher severity, explain to me why the same argument was not made for use of undefined constants, for which the RFC to deprecate/remove support, passed 41:0. How is one undefined symbol more acceptable than another undefined symbol?
  106996
September 12, 2019 18:07 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay <php-lists@koalephant.com>
wrote:

> > > On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> > > wrote: > > > >> What if Java suddenly said that all properties are suddenly private, and > >>> can only be accessed through getter/setter methods? > >>> > >> > >> If Java announced that the next major version was to make the change > after > >> 95% of userland developers favoured it and over 2/3rds of their > internals > >> team did, I'd think "huh ok I guess they have good reasons". > >> > >> For 20 years people have developed code based on that feature. It was > >>> never considered an error, and often not even considered bad practice > >> > >> > >> You seem to be arguing against *ever* changing something that a majority > >> once thought was good, and fundamental to a given system. Lots of things > >> fall into that category - restricting voting to men, segregation, etc. > >> > > > > Now you're just being silly. I actually don't have a problem with > > fundamental language change, provided that the positives that are gained > > far outweigh the negatives of the BC break and there is no other way to > > accomplish those positives without such a BC break. > > > > There are a myriad of ways to achieve what the RFC attempts to achieve. > > Whether that's analysis tools, custom error handlers, detailed code > > reviews, etc. Nothing prevents anyone from initializing all of their > > variables or performing as many sanity checks on a variable before > > accessing it as they want to. Nothing in the RFC is required to implement > > other new functionality like enums, union types, variable typing, etc. > > > > I also think it's a bit of a stretch to compare something like variable > > initialization with things that denied people their basic human rights. > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > > Please, will someone arguing against making use of undefined variables a > higher severity, explain to me why the same argument was not made for use > of undefined constants, for which the RFC to deprecate/remove support, > passed 41:0. > > How is one undefined symbol more acceptable than another undefined symbol?
First of all, I wasn't as involved with this list back then as I was now. However, I can see a fundamental difference in the two. Not needing to initialize variables just for the sake of initializing them (e.g. just doing $i++ without $i=0 before it) is something that is going to behave as expected almost all of the time. When it doesn't, you can easily initialize $i to a non-zero value, or, you can initialize it to zero if you want - it doesn't hurt anything. An undefined constant getting converted to a string, though, is much less likely to be the intended behavior. String literals are required to be in quotes. Constants can never be in quotes. Assuming that the token that looks like a constant, but can't be because the constant didn't exist, so, we'll pretend it's a string even though it doesn't match the proper syntax for such a token is drastically different than assuming the variable you are incrementing that wasn't initialized is 0, or, that the variable you are concatenating to, but wasn't initialized, is an empty string. Finally, let's pretend that the undefined constants RFC was a horrible RFC that shouldn't have passed. The fact that it did has no impact on whether or not this RFC should pass. -- Chase Peeler chasepeeler@gmail.com
  107002
September 12, 2019 18:24 php-lists@koalephant.com (Stephen Reay)
> On 13 Sep 2019, at 01:07, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay <php-lists@koalephant.com> wrote: > > > On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> > > wrote: > > > >> What if Java suddenly said that all properties are suddenly private, and > >>> can only be accessed through getter/setter methods? > >>> > >> > >> If Java announced that the next major version was to make the change after > >> 95% of userland developers favoured it and over 2/3rds of their internals > >> team did, I'd think "huh ok I guess they have good reasons". > >> > >> For 20 years people have developed code based on that feature. It was > >>> never considered an error, and often not even considered bad practice > >> > >> > >> You seem to be arguing against *ever* changing something that a majority > >> once thought was good, and fundamental to a given system. Lots of things > >> fall into that category - restricting voting to men, segregation, etc. > >> > > > > Now you're just being silly. I actually don't have a problem with > > fundamental language change, provided that the positives that are gained > > far outweigh the negatives of the BC break and there is no other way to > > accomplish those positives without such a BC break. > > > > There are a myriad of ways to achieve what the RFC attempts to achieve. > > Whether that's analysis tools, custom error handlers, detailed code > > reviews, etc. Nothing prevents anyone from initializing all of their > > variables or performing as many sanity checks on a variable before > > accessing it as they want to. Nothing in the RFC is required to implement > > other new functionality like enums, union types, variable typing, etc. > > > > I also think it's a bit of a stretch to compare something like variable > > initialization with things that denied people their basic human rights. > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > > Please, will someone arguing against making use of undefined variables a higher severity, explain to me why the same argument was not made for use of undefined constants, for which the RFC to deprecate/remove support, passed 41:0. > > How is one undefined symbol more acceptable than another undefined symbol? > > First of all, I wasn't as involved with this list back then as I was now. However, I can see a fundamental difference in the two. Not needing to initialize variables just for the sake of initializing them (e.g. just doing $i++ without $i=0 before it) is something that is going to behave as expected almost all of the time. When it doesn't, you can easily initialize $i to a non-zero value, or, you can initialize it to zero if you want - it doesn't hurt anything. > > An undefined constant getting converted to a string, though, is much less likely to be the intended behavior. String literals are required to be in quotes. Constants can never be in quotes. Assuming that the token that looks like a constant, but can't be because the constant didn't exist, so, we'll pretend it's a string even though it doesn't match the proper syntax for such a token is drastically different than assuming the variable you are incrementing that wasn't initialized is 0, or, that the variable you are concatenating to, but wasn't initialized, is an empty string. > > Finally, let's pretend that the undefined constants RFC was a horrible RFC that shouldn't have passed. The fact that it did has no impact on whether or not this RFC should pass. > > -- > Chase Peeler > chasepeeler@gmail.com
Apologies if you thought I was specifically replying to you Chase, I simply hit reply-all to the last message I had. The RFC I referred to explicitly describes the use-case for the (mis-)feature it removed:
> The current behaviour appears to have been added as an attempt to guess the user's intention, and continue gracefully.
Sounds familiar, doesn’t it? “If I write $foo++ and $foo is undefined, it should know what I mean”.
> The value of keeping the current behaviour would be for programs written to deliberately take advantage of it. In particular, I have seen sample code of the form $_GET[bar] where bar is taken to be the string key bar.
So, it clearly was (ab)used. IMO this also flies in the face of the “we can’t change behaviour” argument - bare word strings were added around 20 years ago, and yet not a single person thought it worthwhile voting against the deprecation and removal of this behaviour?
  107003
September 12, 2019 18:25 matthewmatthew@gmail.com (Matthew Brown)
I'm sure that some people wrote code like this, expecting it to always work
in PHP:

if ($some_condition) define("HELLO", 0);
if (HELLO) { var_dump("got here"); }

The equivalent, relying on buggy behaviour, PHP code looks like

if ($some_condition) $hello = 1;
if (!$hello) { var_dump("got here"); }

If preventing undefined constants wasn't a fundamental change to the
language, neither is preventing undefined variables.

>
  106991
September 12, 2019 17:54 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> What if Java suddenly said that all properties are suddenly private, and >> can only be accessed through getter/setter methods? >> > > If Java announced that the next major version was to make the change after > 95% of userland developers favoured it and over 2/3rds of their internals > team did, I'd think "huh ok I guess they have good reasons". > > I call shenanigans on that 95% number. Can you please back that up?
Personally, I don't think it's even possible to gauge userland support because the vast majority of userland developers aren't involved in the community at all. Those people don't even know this is being discussed, and probably won't until they start looking to upgrade to PHP 8.
> For 20 years people have developed code based on that feature. It was >> never considered an error, and often not even considered bad practice > > > You seem to be arguing against *ever* changing something that a majority > once thought was good, and fundamental to a given system. Lots of things > fall into that category - restricting voting to men, segregation, etc. > >>
-- Chase Peeler chasepeeler@gmail.com
  106993
September 12, 2019 17:58 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> > wrote: > > > What if Java suddenly said that all properties are suddenly private, and > >> can only be accessed through getter/setter methods? > >> > > > > If Java announced that the next major version was to make the change > after > > 95% of userland developers favoured it and over 2/3rds of their internals > > team did, I'd think "huh ok I guess they have good reasons". > > > > > I call shenanigans on that 95% number. Can you please back that up? > Personally, I don't think it's even possible to gauge userland > support because the vast majority of userland developers aren't involved in > the community at all. Those people don't even know this is being discussed, > and probably won't until they start looking to upgrade to PHP 8. > > I'm sure you need to read the message properly before replying, he ain't talking about PHP there...
Even 95% can be called anything(of users who are involved in the community, who knows, who are actual users, etc)
> > > For 20 years people have developed code based on that feature. It was > >> never considered an error, and often not even considered bad practice > > > > > > You seem to be arguing against *ever* changing something that a majority > > once thought was good, and fundamental to a given system. Lots of things > > fall into that category - restricting voting to men, segregation, etc. > > > >> > > -- > Chase Peeler > chasepeeler@gmail.com >
  106999
September 12, 2019 18:11 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:58 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> > > On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler <chasepeeler@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> >> wrote: >> >> > What if Java suddenly said that all properties are suddenly private, and >> >> can only be accessed through getter/setter methods? >> >> >> > >> > If Java announced that the next major version was to make the change >> after >> > 95% of userland developers favoured it and over 2/3rds of their >> internals >> > team did, I'd think "huh ok I guess they have good reasons". >> > >> > >> I call shenanigans on that 95% number. Can you please back that up? >> Personally, I don't think it's even possible to gauge userland >> support because the vast majority of userland developers aren't involved >> in >> the community at all. Those people don't even know this is being >> discussed, >> and probably won't until they start looking to upgrade to PHP 8. >> >> I'm sure you need to read the message properly before replying, he ain't > talking about PHP there... > > Even 95% can be called anything(of users who are involved in the > community, who knows, who are actual users, etc) > >> >> No, I think you misunderstood. I said "What if Java did XYZ" - The reply
was "If 95% of userland Java developers supported such a change..." That implies that 95% of userland PHP developers support the changes in the RFC. It wouldn't make sense to say "Well, if 95% of Java userland developers supported the change, then it would make sense, just like we should pass this RFC that 45% of PHP userland developers support"
> > For 20 years people have developed code based on that feature. It was >> >> never considered an error, and often not even considered bad practice >> > >> > >> > You seem to be arguing against *ever* changing something that a majority >> > once thought was good, and fundamental to a given system. Lots of things >> > fall into that category - restricting voting to men, segregation, etc. >> > >> >> >> >> -- >> Chase Peeler >> chasepeeler@gmail.com >> >
-- Chase Peeler chasepeeler@gmail.com
  106987
September 12, 2019 17:37 kjarli@gmail.com (Lynn)
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. Regards, Lynn van der Berg
  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
  106988
September 12, 2019 17:39 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatthew@gmail.com> > wrote: > > > that don't fundamentally change the language > > > > > > There's clearly a big disagreement about whether this is a fundamental > > change or not. > > > > Preventing something that the entire field of software engineering frowns > > upon (and that most PHP developers avoid like the plague) doesn't seem > like > > a *fundamental* change. > > > > > I would argue that this is exactly such a change. The flexibility of PHP > has often been touted as a feature and something that sets it apart. > Whether that's good or bad is, frankly, irrelevant. There are valid reasons > for not always initializing variables or array keys.
The major valid reason i see is creating a bolierplate or being lazy to initialize the variable with even null or similar null-type depending on its context. It might be a bad reason in your opinion, but others view it as perfectly
> acceptable.
Who are those "others"? I think he(me included) is also one of those "others" that view it as bad programming style... For 20 years people have developed code based on that feature. It was never
> considered an error, and often not even considered bad practice.
It was considered an error, that's why you were been warned or given notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of already-problematic-file.php" and only if we want to remove Notice,Warning or Error in the language.
> To suddenly define it as such is the exact definition of a fundamental > change > to the language itself. > Fundamental is always "fundamental", i think there's no good definition for
it in this context, so leave fundamental changes out of this discussion as something totally bad been cleaned up is a fundamental change and something new but not used right and changed to be used right is also fundamental...
> > What if Java suddenly said that all properties are suddenly private, and > can only be accessed through getter/setter methods? The fact that you > should make properties private and use such methods is a practice that was > drilled into me from day one. Would that justify making such a change, > though? > > I'm not sure how this relates, i think Java would let you see the good or bad, it's up to you to see or not from their view, let the majority move
forward and don't be a stopping stone in moving this language past the 1993 bondage(needle-haystack, inconsistent naming and many issues we couldn't count)...
  106990
September 12, 2019 17:51 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:39 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> > > On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler <chasepeeler@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatthew@gmail.com> >> wrote: >> >> > that don't fundamentally change the language >> > >> > >> > There's clearly a big disagreement about whether this is a fundamental >> > change or not. >> > >> > Preventing something that the entire field of software engineering >> frowns >> > upon (and that most PHP developers avoid like the plague) doesn't seem >> like >> > a *fundamental* change. >> > >> > >> I would argue that this is exactly such a change. The flexibility of PHP >> has often been touted as a feature and something that sets it apart. >> Whether that's good or bad is, frankly, irrelevant. There are valid >> reasons >> for not always initializing variables or array keys. > > The major valid reason i see is creating a bolierplate or being lazy to > initialize the variable with even null or similar null-type depending on > its context. > > It might be a bad reason in your opinion, but others view it as perfectly >> acceptable. > > Who are those "others"? > I think he(me included) is also one of those "others" that view it as bad > programming style... > > For 20 years people have developed code based on that feature. It was never >> considered an error, and often not even considered bad practice. > > It was considered an error, that's why you were been warned or given > notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of > already-problematic-file.php" and only if we want to remove Notice,Warning > or Error in the language. >
No, as discussed previously, notices were never meant to signify a definite issue. They are "Hey, this might be an issue, it might not, maybe check it out if you want?" thing. This RFC is proposing that we actually halt execution of programs that currently work perfectly fine and run exactly as they were intended to.
> To suddenly define it as such is the exact definition of a fundamental >> change >> to the language itself. >> > Fundamental is always "fundamental", i think there's no good definition > for it in this context, so leave fundamental changes out of this discussion > as something totally bad been cleaned up is a fundamental change and > something new but not used right and changed to be used right is also > fundamental... >
I would said fundamental is any behavior that is expected and intended. At this point, the fact that you don't have to initialize your variables is an intended feature of the language. That means people should be able to depend on such a feature existing. The fact that you don't like it shouldn't be a justification for breaking that, especially when nothing is stopping you from being as strict as you want with your own code. You can also hold any third party libraries that you use to the same standard if you want.
> >> What if Java suddenly said that all properties are suddenly private, and >> can only be accessed through getter/setter methods? The fact that you >> should make properties private and use such methods is a practice that was >> drilled into me from day one. Would that justify making such a change, >> though? >> >> I'm not sure how this relates, i think Java would let you see the good or > bad, it's up to you to see or not from their view, let the majority move > forward and don't be a stopping stone in moving this language past the 1993 > bondage(needle-haystack, inconsistent naming and many issues we couldn't > count)... >
It relates because right now, it's a feature of Java that you can make properties public and then modify those directly from outside the class. Since it's an intended feature, a lot of people have written code that directly accesses public properties.You could argue the only use-case for doing so is that they are too lazy to write the getter/setter methods, but that doesn't change the fact that such code exists and is not an error or even a misuse of a current feature. -- Chase Peeler chasepeeler@gmail.com
  106968
September 12, 2019 15:01 j.boggiano@seld.be (Jordi Boggiano)
On 12/09/2019 16:44, Zeev Suraski wrote:
> Similarly - adding typed variables - is certainly a future option. Changing > PHP to require typed variables (without opting in) - is well outside of the > internals@ mandate. > > > > For areas like that - our options are either doing nothing, or providing > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > 2nd option, but there is no 3rd.
While I am not sure your tone will be well received by your target audience, I just wanted to say I tend to agree. 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. I know I have a bunch of old stuff running which tends to litter the error logs with notices, and I don't have time to go fix them so I ignore because it's fine and it works. For new projects, what I do, and what I am pretty sure 99% of the "strict camp" does is essentially boiling down to:     set_error_handler(function () { throw new \RuntimeException(); }); That's our global strictness flag right there. It's been available for ages. I don't see why we need to take something away from others to make such an easy workaround a little less needed. Especially as I don't imagine we will drop the error handlers. I sure will keep mine around to keep failing warnings etc as hard fatals. So what do we gain exactly? Best, Jordi -- Jordi Boggiano @seldaek - https://seld.be
  106973
September 12, 2019 15:11 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 11:01 AM Jordi Boggiano boggiano@seld.be> wrote:

> On 12/09/2019 16:44, Zeev Suraski wrote: > > Similarly - adding typed variables - is certainly a future option. > Changing > > PHP to require typed variables (without opting in) - is well outside of > the > > internals@ mandate. > > > > > > > > For areas like that - our options are either doing nothing, or providing > > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > > 2nd option, but there is no 3rd. > > > While I am not sure your tone will be well received by your target > audience, I just wanted to say I tend to agree. > > My thoughts as well.
> 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. > > Yes!
> I know I have a bunch of old stuff running which tends to litter the > error logs with notices, and I don't have time to go fix them so I > ignore because it's fine and it works. > > Can't make that argument. Be prepared to be told how easy it should be for
you to fix it, or, how it's technical debt (ignoring the fact that it's not technical debt currently, since there is nothing wrong with what was written) and you're just making things worse by not taking care of it.
> For new projects, what I do, and what I am pretty sure 99% of the > "strict camp" does is essentially boiling down to: > > set_error_handler(function () { throw new \RuntimeException(); }); > > That's our global strictness flag right there. It's been available for > ages. I don't see why we need to take something away from others to make > such an easy workaround a little less needed. Especially as I don't > imagine we will drop the error handlers. I sure will keep mine around to > keep failing warnings etc as hard fatals. > > So what do we gain exactly? > > That's the argument I've been making all along. There are so many ways to
accomplish what has been proposed without forcing it on those that don't want it. It's not required in order to add new features to the language. It doesn't make the language perform better, either. It's also not taking away something that is definitely a negative feature. It's taking away something that many view as a positive feature of the language. If there was no way to achieve the intended results without making the change, I might be more sympathetic to making it. But there is. Whether it's an error handler like you mentioned above, stricter code reviews, public shaming for anyone that doesn't initialize their variables, or any of the myriad of other options.
> Best, > Jordi > > -- > > Jordi Boggiano > @seldaek - https://seld.be > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  106977
September 12, 2019 16:16 matthewmatthew@gmail.com (Matthew Brown)
Without your contributions in the early 2000s, PHP likely would not enjoy
the popularity it does today.

But I don't think that gives you veto power over the entire process. You
haven't made any significant contributions to the codebase in over a
decade, and yet the language has still gained many more users in that time
frame, with some fairly major backwards-incompatible changes along the way.

I think you have to come to terms with the fact that today you are a single
vote in this process — though you are, of course, free to write your own
RFCs.

Best wishes,

Matt

On Thu, 12 Sep 2019 at 10:44, Zeev Suraski <zeev@php.net> wrote:

> I was really really hoping that we will avert having to dive into this and > instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we > need > to make something clear. > > > > The RFC process was never, ever meant to handle fundamental changes to the > language. It was meant to deal predominantly with additions to the > language, as can be inferred from numerous parts in the phrasing. As I > mentioned in the past - it wasn't even intended to deal with simpler > deprecations, but it appears that the cat is out of the bag on this one. > However, the fact the cat is out, doesn't mean we'll let a tiger waltz out > of the same bag. Using the RFC to deprecate fundamental behaviors of the > language - such as how the language deals with undefined variables - is > simply off the table. > > > > You may be wondering, in that case, what processes do we have to deal with > such changes then? The answer is simple. We don't. We don't have to have > them either - the fundamental language behaviors are here to stay. > > Deprecating the ability to rely on the expected default value of > uninitialized variables falls squarely in that category. > > > > Reclassifying a notice to a warning is a possibility - people's code will > still run, and they'll be able to continue using these behaviors going > forward as well if they want to (perhaps with minor tweaks to error > reporting levels). Turning a notice to an error isn't reclassifying an > error level. It's deprecating a behavior - and we're not talking about > some > esoteric extension, but a documented, well-defined, fundamental behavior of > the language for over two decades. The fact many of you think it's > horrible > does not change that. Deprecating such fundamentals is simply outside of > the mandate of internals@, regardless of whatever majority appears to > exist > in favor of it at a given time. > > > > Similarly - adding typed variables - is certainly a future option. > Changing > PHP to require typed variables (without opting in) - is well outside of the > internals@ mandate. > > > > For areas like that - our options are either doing nothing, or providing > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > 2nd option, but there is no 3rd. > > > > Zeev > > > >
  106979
September 12, 2019 16:39 Andreas Heigl <andreas@heigl.org>
--KBQ22qBJZUetMbeu4mtLToJkiQ2Gns1BF
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey Zeev.

I'm not that deep into @internals and might not get the subtle subtext.
English is not my native tongue so I might phrase things in a way that
doesn't transport the whole meaning of my thoughts. But your Mail really
left me curious:

On Thu, 12 Sep 2019 at 10:44, Zeev Suraski <zeev@php.net> wrote:

> I was really really hoping that we will avert having to dive into this = and
> instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we=
> need > to make something clear. > > > > The RFC process was never, ever meant to handle fundamental changes to = the
> language. It was meant to deal predominantly with additions to the > language, as can be inferred from numerous parts in the phrasing. As I=
> mentioned in the past - it wasn't even intended to deal with simpler > deprecations, but it appears that the cat is out of the bag on this one= =2E
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz = out
> of the same bag. Using the RFC to deprecate fundamental behaviors of t= he
> language - such as how the language deals with undefined variables - is=
> simply off the table.
Given the fact that you have the authority to say so, what actually *is* the process then to make "fundamental changes to the language"?
> > > > You may be wondering, in that case, what processes do we have to deal w= ith
> such changes then? The answer is simple. We don't. We don't have to = have
> them either - the fundamental language behaviors are here to stay.
But we still need processes to define which are the "fundamental language behaviours". And as change is the only constant in software-development, these "fundamental language behaviours" might, can and probably should be changeable. I'm not saying they need to change, but it has to be possible to change them. Otherwise we would still program business-logic in C as that was Rasmus' fundamental idea IIRC (Correct me if I'm wrong)
> > Deprecating the ability to rely on the expected default value of > uninitialized variables falls squarely in that category. > > > > Reclassifying a notice to a warning is a possibility - people's code wi= ll
> still run, and they'll be able to continue using these behaviors going > forward as well if they want to (perhaps with minor tweaks to error > reporting levels). Turning a notice to an error isn't reclassifying an=
> error level. It's deprecating a behavior - and we're not talking about=
> some > esoteric extension, but a documented, well-defined, fundamental behavio= r of
> the language for over two decades. The fact many of you think it's > horrible > does not change that. Deprecating such fundamentals is simply outside = of
> the mandate of internals@, regardless of whatever majority appears to > exist > in favor of it at a given time. > > > > Similarly - adding typed variables - is certainly a future option. > Changing > PHP to require typed variables (without opting in) - is well outside of= the
> internals@ mandate.
So tell us, what is *insight* the @internals mandate. And who has the mandate to change the things @internals does not have the mandate to. =46rom what i see you tell us (@internals) "You're not allowed to do so, but I will not tell you who *is* allowed." So for me that raises two main questions: 1. Who then has the mandate to do so? 2. By what authority are you making this statement? I'm looking forward to your answers. Cheers Andreas
> > > > For areas like that - our options are either doing nothing, or providin= g
> opt-in mechanisms to cater to stricter-loving audiences. I'm all for t= he
> 2nd option, but there is no 3rd. > > > > Zeev
--=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --KBQ22qBJZUetMbeu4mtLToJkiQ2Gns1BF--
  107005
September 12, 2019 18:35 zeev@php.net (Zeev Suraski)
On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote:

> > > > You may be wondering, in that case, what processes do we have to deal > with > > such changes then? The answer is simple. We don't. We don't have to > have > > them either - the fundamental language behaviors are here to stay. > > But we still need processes to define which are the "fundamental > language behaviours". And as change is the only constant in > software-development, these "fundamental language behaviours" might, can > and probably should be changeable. I'm not saying they need to change, > but it has to be possible to change them. Otherwise we would still > program business-logic in C as that was Rasmus' fundamental idea IIRC > (Correct me if I'm wrong) >
You're right. The thing is this - as I said, the RFC process was designed to address additions to the language - as is implied in numerous places (both the part I quoted from the RFC itself, as well as elements in RFC template as well as the RFC howto). It was never meant to handle deprecations - mainly because we simply weren't doing much of that back in the days where it was introduced. It was meant to resolve the issue at hand at the time (and in the years leading up to it) - which is a formal way to agree on which features make it in and which ones don't. Now, over the years (and more and more as of late) - it started being used for deprecations. But these deprecations have become more and more extreme recently in terms of their impact. Of course I do think deprecations should be allowed, like in any other language. I do think we need to have a higher bar for them in general (both in terms of a clear benefits and required majority - as is implied in the Voting RFC) - but since we've grown used to using 2/3 for them - and given the pro-deprecation bias of the current composition of internals@ - I also realize it will be tough to do. But when dealing with deprecation proposals that are likely to effect a very sizable subset of our userbase and codebase, and deal with some of the most basic building blocks of the language - we simply can't start using the same process. We never have in the past (none of the deprecations we voted on since 2013 comes even remotely close to the level of impact of the two proposals that have been put forward to a vote in the recent couple of months, and the more recent one clearly far outdoes the prior one in terms of impact). Should we have 'woken up' many years ago when we started using the Voting RFC for deprecations it wasn't meant to handle? Probably. It would have been much easier to install a new mechanism. But it doesn't mean we should repeat the same mistake, now that it begins to be used to deprecate mainstream language behaviors. In terms of telling one from the other - right now, I'm afraid it's a bit like some other things that fall into the category of 'you know it when you see it'. I think few can deny that far-reaching effect of changing how variables behave in a language, whether they think it's a change for the better or for the worse. But I think it *may* be possible to formally define. These are just random thoughts at this point - but we could have a set of apps/frameworks that we use as a testing bed to check the level of impact of a certain proposal. If that impact is above a certain threshold - it will be considered fundamental. Of course, things like WordPress, Joomla and MediaWiki would have to be a part of that - not just modern frameworks. It's still not ideal since it doesn't account for the majority of PHP code out there which isn't Open Source - but it may be a start. There may be other ways - such as letting folks run that analysis on their own code behind the firewall and report results back. But there's also a simpler solution to this. This 'can of worms' as Arvids called it, wouldn't have been opened had we agreed to focus on extending PHP instead of trying to replace it with something else. This is what the RFC process was meant to facilitate. It still can, but for that, we need to change the dynamics from a zero-sum game to a goal of a win/win. Yes, I realize that I'm sounding like a broken record. But call me naive - I'm still hoping that given it obviously can be done from a technical perspective (in a wide variety of ways too) - we can find the good will to do it from a human perspective. Zeev
>
  107006
September 12, 2019 18:51 peterkokot@gmail.com (Peter Kokot)
On Thu, 12 Sep 2019 at 20:35, Zeev Suraski <zeev@php.net> wrote:
> > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote: > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > with > > > such changes then? The answer is simple. We don't. We don't have to > > have > > > them either - the fundamental language behaviors are here to stay. > > > > But we still need processes to define which are the "fundamental > > language behaviours". And as change is the only constant in > > software-development, these "fundamental language behaviours" might, can > > and probably should be changeable. I'm not saying they need to change, > > but it has to be possible to change them. Otherwise we would still > > program business-logic in C as that was Rasmus' fundamental idea IIRC > > (Correct me if I'm wrong) > > > > You're right. The thing is this - as I said, the RFC process was designed > to address additions to the language - as is implied in numerous places > (both the part I quoted from the RFC itself, as well as elements in RFC > template as well as the RFC howto). It was never meant to handle > deprecations - mainly because we simply weren't doing much of that back in > the days where it was introduced. It was meant to resolve the issue at > hand at the time (and in the years leading up to it) - which is a formal > way to agree on which features make it in and which ones don't. > Now, over the years (and more and more as of late) - it started being used > for deprecations. But these deprecations have become more and more extreme > recently in terms of their impact. Of course I do think deprecations > should be allowed, like in any other language. I do think we need to have > a higher bar for them in general (both in terms of a clear benefits and > required majority - as is implied in the Voting RFC) - but since we've > grown used to using 2/3 for them - and given the pro-deprecation bias of > the current composition of internals@ - I also realize it will be tough to > do. But when dealing with deprecation proposals that are likely to effect > a very sizable subset of our userbase and codebase, and deal with some of > the most basic building blocks of the language - we simply can't start > using the same process. We never have in the past (none of the > deprecations we voted on since 2013 comes even remotely close to the level > of impact of the two proposals that have been put forward to a vote in the > recent couple of months, and the more recent one clearly far outdoes the > prior one in terms of impact). > > Should we have 'woken up' many years ago when we started using the Voting > RFC for deprecations it wasn't meant to handle? Probably. It would have > been much easier to install a new mechanism. But it doesn't mean we should > repeat the same mistake, now that it begins to be used to deprecate > mainstream language behaviors. > > In terms of telling one from the other - right now, I'm afraid it's a bit > like some other things that fall into the category of 'you know it when you > see it'. I think few can deny that far-reaching effect of changing how > variables behave in a language, whether they think it's a change for the > better or for the worse. But I think it *may* be possible to formally > define. These are just random thoughts at this point - but we could have a > set of apps/frameworks that we use as a testing bed to check the level of > impact of a certain proposal. If that impact is above a certain threshold > - it will be considered fundamental. Of course, things like WordPress, > Joomla and MediaWiki would have to be a part of that - not just modern > frameworks. It's still not ideal since it doesn't account for the majority > of PHP code out there which isn't Open Source - but it may be a start. > There may be other ways - such as letting folks run that analysis on their > own code behind the firewall and report results back. > > But there's also a simpler solution to this. This 'can of worms' as Arvids > called it, wouldn't have been opened had we agreed to focus on extending > PHP instead of trying to replace it with something else. This is what the > RFC process was meant to facilitate. It still can, but for that, we need > to change the dynamics from a zero-sum game to a goal of a win/win. Yes, I > realize that I'm sounding like a broken record. But call me naive - I'm > still hoping that given it obviously can be done from a technical > perspective (in a wide variety of ways too) - we can find the good will to > do it from a human perspective. > > Zeev > > > >
Just a dumb idea, since there clearly is a majority in favor of the change with these warnings and strictness and all that now... Why not making something like an LTS PHP 7.x where all the legacy code would work OK as long as practically possible and 8.x+ would be the future of what the developers want and not what business wants? One who won't upgrade due to the BC breaks also won't need the new features anyway very realistically. Microsoft, Zend, and Red Hat have been showing that this is actually possible. How smart this is for the PHP progress is another story, but for the business it might be good to think about this also I guess: https://github.com/microsoft/php-src/releases So, to make some sort of a milestone with some of the versions - either 8 or 9 or something. -- Peter Kokot
  107007
September 12, 2019 19:00 michael.babker@gmail.com (Michael Babker)
On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Just a dumb idea, since there clearly is a majority in favor of the > change with these warnings and strictness and all that now... Why not > making something like an LTS PHP 7.x where all the legacy code would > work OK as long as practically possible and 8.x+ would be the future > of what the developers want and not what business wants? One who won't > upgrade due to the BC breaks also won't need the new features anyway > very realistically. >
Please don't tie the notion of LTS with the idea that a new major can break BC at will or create larger scale breaks because the previous major has extended support. Sooner or later that will end up back at the ++ idea and fragmentation encouraged by the language is a bad idea.
  107010
September 12, 2019 19:06 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 8:00 PM Michael Babker babker@gmail.com>
wrote:

> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> wrote: > > > Just a dumb idea, since there clearly is a majority in favor of the > > change with these warnings and strictness and all that now... Why not > > making something like an LTS PHP 7.x where all the legacy code would > > work OK as long as practically possible and 8.x+ would be the future > > of what the developers want and not what business wants? One who won't > > upgrade due to the BC breaks also won't need the new features anyway > > very realistically. > > > > Please don't tie the notion of LTS with the idea that a new major can break > BC at will or create larger scale breaks because the previous major has > extended support. Sooner or later that will end up back at the ++ idea and > fragmentation encouraged by the language is a bad idea. >
Not sure you are really seeing the goal... Why is LTS not a good idea? And, if the majority want this or that, can we just blow everything into full dictatorship where i can host my fork of PHP doing uncountable unwanted things i can call it..? Any which way, i think the majority of us are tired of writing bad codes, but since the language is allowing it we don't have choices than to spend some hours or weeks later debugging the wrong or right line we did that last "big mistake", who knows there might be another line smiling coz i haven't detected it...
  107011
September 12, 2019 19:11 michael.babker@gmail.com (Michael Babker)
On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker babker@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> wrote: >> >> > Just a dumb idea, since there clearly is a majority in favor of the >> > change with these warnings and strictness and all that now... Why not >> > making something like an LTS PHP 7.x where all the legacy code would >> > work OK as long as practically possible and 8.x+ would be the future >> > of what the developers want and not what business wants? One who won't >> > upgrade due to the BC breaks also won't need the new features anyway >> > very realistically. >> > >> >> Please don't tie the notion of LTS with the idea that a new major can >> break >> BC at will or create larger scale breaks because the previous major has >> extended support. Sooner or later that will end up back at the ++ idea >> and >> fragmentation encouraged by the language is a bad idea. >> > > Not sure you are really seeing the goal... > > Why is LTS not a good idea? >
I'm not saying LTS is a bad idea. I'm saying using LTS to justify shipping larger scale BC breaks, such as the changes suggested in the last couple of "contentious" RFCs in a major version because "hey, we have a LTS version you can use that until you're ready to deal with the backlog of BC breaks created" is a bad idea. For the record, I happen to agree with as these RFCs would have minimal impact on my day-to-day work, but having also been in the role of a maintainer of open source libraries and applications I also grasp why these types of changes can be problematic to the ecosystem (both end users of those libraries and applications and the maintainers of them) and wouldn't jump the gun to ship them without careful consideration.
>
  107013
September 12, 2019 19:17 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 8:11 PM Michael Babker babker@gmail.com>
wrote:

> On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker babker@gmail.com> >> wrote: >> >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> >>> wrote: >>> >>> > Just a dumb idea, since there clearly is a majority in favor of the >>> > change with these warnings and strictness and all that now... Why not >>> > making something like an LTS PHP 7.x where all the legacy code would >>> > work OK as long as practically possible and 8.x+ would be the future >>> > of what the developers want and not what business wants? One who won't >>> > upgrade due to the BC breaks also won't need the new features anyway >>> > very realistically. >>> > >>> >>> Please don't tie the notion of LTS with the idea that a new major can >>> break >>> BC at will or create larger scale breaks because the previous major has >>> extended support. Sooner or later that will end up back at the ++ idea >>> and >>> fragmentation encouraged by the language is a bad idea. >>> >> >> Not sure you are really seeing the goal... >> >> Why is LTS not a good idea? >> > > I'm not saying LTS is a bad idea. I'm saying using LTS to justify > shipping larger scale BC breaks, such as the changes suggested in the last > couple of "contentious" RFCs in a major version because "hey, we have a LTS > version you can use that until you're ready to deal with the backlog of BC > breaks created" is a bad idea. >
> For the record, I happen to agree with as these RFCs would have minimal > impact on my day-to-day work, but having also been in the role of a > maintainer of open source libraries and applications I also grasp why these > types of changes can be problematic to the ecosystem (both end users of > those libraries and applications and the maintainers of them) and wouldn't > jump the gun to ship them without careful consideration. >
Most of these changes wouldn't have been problematic to you if the language has prevented you from writing what we can now consider bad code, so please allow the new PHP developer that newly start using PHP to not follow that your path that will/might hunt him later in the future... There a notices, warning and errors to inform you that this shouldn't have been the use case of this feature and you chose to ignore it and now, we are simplifying things and making those your errors teach you how to write proper codes in the future, you're objecting.. Why not just stay in PHP 7.x? Or were you implying you want hitch-free, no-modification upgrade to PHP 8 from PHP 7.0? If yes, follow the best practices and not suppress error notices. Just My Opinion
  107015
September 12, 2019 19:25 michael.babker@gmail.com (Michael Babker)
On Thu, Sep 12, 2019 at 2:17 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> Most of these changes wouldn't have been problematic to you if the > language has prevented you from writing what we can now consider bad code, > so please allow the new PHP developer that newly start using PHP to not > follow that your path that will/might hunt him later in the future... > > There a notices, warning and errors to inform you that this shouldn't have > been the use case of this feature and you chose to ignore it and now, we > are simplifying things and making those your errors teach you how to write > proper codes in the future, you're objecting.. Why not just stay in PHP 7.x? > > Or were you implying you want hitch-free, no-modification upgrade to PHP 8 > from PHP 7.0? > If yes, follow the best practices and not suppress error notices. >
We're clearly talking past one another so I will be going back to work after this response. I am not saying anything about whether the warnings RFC should pass or fail, or if it makes my code good or bad. I responded explicitly to one idea about creating a LTS version that might somehow make it easier for RFCs like this one to be accepted because users could basically be encouraged to stay on the LTS version if the new major version introduces too many breaking changes, which I think is bad justification for creating a LTS version. I'm not sure how that equates to my code being good or bad or whether I am following someone else's recommended best practices, but that was never the point of discussion.
  107016
September 12, 2019 19:29 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 8:11 PM Michael Babker babker@gmail.com> > wrote: > > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> > > wrote: > > > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < > michael.babker@gmail.com> > >> wrote: > >> > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> > >>> wrote: > >>> > >>> > Just a dumb idea, since there clearly is a majority in favor of the > >>> > change with these warnings and strictness and all that now... Why not > >>> > making something like an LTS PHP 7.x where all the legacy code would > >>> > work OK as long as practically possible and 8.x+ would be the future > >>> > of what the developers want and not what business wants? One who > won't > >>> > upgrade due to the BC breaks also won't need the new features anyway > >>> > very realistically. > >>> > > >>> > >>> Please don't tie the notion of LTS with the idea that a new major can > >>> break > >>> BC at will or create larger scale breaks because the previous major has > >>> extended support. Sooner or later that will end up back at the ++ idea > >>> and > >>> fragmentation encouraged by the language is a bad idea. > >>> > >> > >> Not sure you are really seeing the goal... > >> > >> Why is LTS not a good idea? > >> > > > > I'm not saying LTS is a bad idea. I'm saying using LTS to justify > > shipping larger scale BC breaks, such as the changes suggested in the > last > > couple of "contentious" RFCs in a major version because "hey, we have a > LTS > > version you can use that until you're ready to deal with the backlog of > BC > > breaks created" is a bad idea. > > > > > > For the record, I happen to agree with as these RFCs would have minimal > > impact on my day-to-day work, but having also been in the role of a > > maintainer of open source libraries and applications I also grasp why > these > > types of changes can be problematic to the ecosystem (both end users of > > those libraries and applications and the maintainers of them) and > wouldn't > > jump the gun to ship them without careful consideration. > > > > Most of these changes wouldn't have been problematic to you if the language > has prevented you from writing what we can now consider bad code, so please > allow the new PHP developer that newly start using PHP to not follow that > your path that will/might hunt him later in the future... > > Many of us don't consider it bad code. I've also always initialized
variables when it was required (and many times when it wasn't) even though I wasn't forced to do so. A lot of other people do as well. If it's so important to you, start a program to teach people how you think they should code.
> There a notices, warning and errors to inform you that this shouldn't have > been the use case of this feature and you chose to ignore it and now, we > are simplifying things and making those your errors teach you how to write > proper codes in the future, you're objecting..
As has been discussed before, notices are not the same as warnings and errors. Also, if those things are so wonderful, why can't you use them to catch the issues you are complaining you can't catch right now? Again, you are telling me there is something out there which will allow you to force yourself to write "good code" without forcing me to follow the same restrictions. Yet, you still feel it's necessary to not use those tools, and instead modify the entire language so that I am forced to follow what you deem best practices, even if I don't?
> Why not just stay in PHP 7.x? > > Because other features that I want to utilize will also be added in PHP 8.
Or were you implying you want hitch-free, no-modification upgrade to PHP 8
> from PHP 7.0? >
I never said that. Here we go again with the "I guess you are against all BC breaks" nonsense. If BC breaks are required to add new functionality, or, have a very minimal negative impact, then I don't have a problem with them. This is not one of those cases. It changes a fundamental aspect of the language, an aspect that many people actually like, and it doesn't add any new features to the language, nor is it needed to add any new features to the language.
> If yes, follow the best practices and not suppress error notices. > > Just My Opinion >
-- Chase Peeler chasepeeler@gmail.com
  107017
September 12, 2019 19:39 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 8:29 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> > > On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson <oludonsexy@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 8:11 PM Michael Babker babker@gmail.com> >> wrote: >> >> > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> >> > wrote: >> > >> >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < >> michael.babker@gmail.com> >> >> wrote: >> >> >> >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> >> >>> wrote: >> >>> >> >>> > Just a dumb idea, since there clearly is a majority in favor of the >> >>> > change with these warnings and strictness and all that now... Why >> not >> >>> > making something like an LTS PHP 7.x where all the legacy code would >> >>> > work OK as long as practically possible and 8.x+ would be the future >> >>> > of what the developers want and not what business wants? One who >> won't >> >>> > upgrade due to the BC breaks also won't need the new features anyway >> >>> > very realistically. >> >>> > >> >>> >> >>> Please don't tie the notion of LTS with the idea that a new major can >> >>> break >> >>> BC at will or create larger scale breaks because the previous major >> has >> >>> extended support. Sooner or later that will end up back at the ++ >> idea >> >>> and >> >>> fragmentation encouraged by the language is a bad idea. >> >>> >> >> >> >> Not sure you are really seeing the goal... >> >> >> >> Why is LTS not a good idea? >> >> >> > >> > I'm not saying LTS is a bad idea. I'm saying using LTS to justify >> > shipping larger scale BC breaks, such as the changes suggested in the >> last >> > couple of "contentious" RFCs in a major version because "hey, we have a >> LTS >> > version you can use that until you're ready to deal with the backlog of >> BC >> > breaks created" is a bad idea. >> > >> >> >> > For the record, I happen to agree with as these RFCs would have minimal >> > impact on my day-to-day work, but having also been in the role of a >> > maintainer of open source libraries and applications I also grasp why >> these >> > types of changes can be problematic to the ecosystem (both end users of >> > those libraries and applications and the maintainers of them) and >> wouldn't >> > jump the gun to ship them without careful consideration. >> > >> >> Most of these changes wouldn't have been problematic to you if the >> language >> has prevented you from writing what we can now consider bad code, so >> please >> allow the new PHP developer that newly start using PHP to not follow that >> your path that will/might hunt him later in the future... >> >> > Many of us don't consider it bad code. I've also always initialized > variables when it was required (and many times when it wasn't) even though > I wasn't forced to do so. A lot of other people do as well. If it's so > important to you, start a program to teach people how you think they should > code. > > >> There a notices, warning and errors to inform you that this shouldn't have >> been the use case of this feature and you chose to ignore it and now, we >> are simplifying things and making those your errors teach you how to write >> proper codes in the future, you're objecting.. > > > As has been discussed before, notices are not the same as warnings and > errors. Also, if those things are so wonderful, why can't you use them to > catch the issues you are complaining you can't catch right now? Again, you > are telling me there is something out there which will allow you to force > yourself to write "good code" without forcing me to follow the same > restrictions. Yet, you still feel it's necessary to not use those tools, > and instead modify the entire language so that I am forced to follow what > you deem best practices, even if I don't? > > > >> Why not just stay in PHP 7.x? >> >> Because other features that I want to utilize will also be added in PHP > 8. > > I think it's all up to you to decide if those features you need would be worth it moving to PHP 8(perhaps helping you clean up some codes i would
seem as bad practice IMO) or those features are not worth cleaning up for( then you can stay on PHP 7, even 5 for as long as you wan to)... In all of these, those who would upgrade would do so and those who won't would never upgrade coz they don't see good reasons to or such codes are not more in maintenance...
> Or were you implying you want hitch-free, no-modification upgrade to PHP 8 >> from PHP 7.0? >> > > I never said that. Here we go again with the "I guess you are against all > BC breaks" nonsense. If BC breaks are required to add new functionality, > or, have a very minimal negative impact, then I don't have a problem with > them. This is not one of those cases. It changes a fundamental aspect of > the language, an aspect that many people actually like, and it doesn't add > any new features to the language, nor is it needed to add any new features > to the language. > > >> If yes, follow the best practices and not suppress error notices. >> >> Just My Opinion >> > > > -- > Chase Peeler > chasepeeler@gmail.com >
I think i also have some stuffs to do off this list, perhaps i might check the list later before bed or wheni get home. Have a nice time voting as you deem fit and as you best think would be good for you and everyone(maybe?).
  107021
September 12, 2019 20:59 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
Hi guys,

> Many of us don't consider it bad code. I've also always initialized > variables when it was required (and many times when it wasn't) even though > I wasn't forced to do so. A lot of other people do as well. If it's so > important to you, start a program to teach people how you think they should
> code.
One problem that needs to be understood is that PHP is used by a lot of users. Because it's easy to pick up and you have fast feedback it probably have a higher percentage of juniors than average. How language was 10 years ago it didn't helped them much in learning and they did lot of mistakes. Some of those mistakes cost companies lots of money and, in time, people got to the conclusion that PHP is bad. This is a very important thing!, Yes you can write working great code in PHP but it's very easy to write working bad code as well. And it's not about you and me or the other persons chatting here, it's about the rest of the world. PHP improved on it's bad image in the later years but this needs to continue. IMO, one thing that we need to also do is to make the language image better. With this in mind, I believe the "undefined variable" error will be a step forward. It's not about if you don't consider it bad code and that apparently the majority consider it good. It's that if language wouldn't allow you to write that code it will benefit the language image and the rest of the PHP comunity. Also, I would also like to remind of this: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md I think some parts might have been violated multiple time in this thread. Regards, Alex On Thu, Sep 12, 2019 at 10:29 PM Chase Peeler <chasepeeler@gmail.com> wrote:
> On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson <oludonsexy@gmail.com> > wrote: > > > On Thu, Sep 12, 2019 at 8:11 PM Michael Babker babker@gmail.com > > > > wrote: > > > > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> > > > wrote: > > > > > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < > > michael.babker@gmail.com> > > >> wrote: > > >> > > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> > > >>> wrote: > > >>> > > >>> > Just a dumb idea, since there clearly is a majority in favor of the > > >>> > change with these warnings and strictness and all that now... Why > not > > >>> > making something like an LTS PHP 7.x where all the legacy code > would > > >>> > work OK as long as practically possible and 8.x+ would be the > future > > >>> > of what the developers want and not what business wants? One who > > won't > > >>> > upgrade due to the BC breaks also won't need the new features > anyway > > >>> > very realistically. > > >>> > > > >>> > > >>> Please don't tie the notion of LTS with the idea that a new major can > > >>> break > > >>> BC at will or create larger scale breaks because the previous major > has > > >>> extended support. Sooner or later that will end up back at the ++ > idea > > >>> and > > >>> fragmentation encouraged by the language is a bad idea. > > >>> > > >> > > >> Not sure you are really seeing the goal... > > >> > > >> Why is LTS not a good idea? > > >> > > > > > > I'm not saying LTS is a bad idea. I'm saying using LTS to justify > > > shipping larger scale BC breaks, such as the changes suggested in the > > last > > > couple of "contentious" RFCs in a major version because "hey, we have a > > LTS > > > version you can use that until you're ready to deal with the backlog of > > BC > > > breaks created" is a bad idea. > > > > > > > > > > For the record, I happen to agree with as these RFCs would have minimal > > > impact on my day-to-day work, but having also been in the role of a > > > maintainer of open source libraries and applications I also grasp why > > these > > > types of changes can be problematic to the ecosystem (both end users of > > > those libraries and applications and the maintainers of them) and > > wouldn't > > > jump the gun to ship them without careful consideration. > > > > > > > Most of these changes wouldn't have been problematic to you if the > language > > has prevented you from writing what we can now consider bad code, so > please > > allow the new PHP developer that newly start using PHP to not follow that > > your path that will/might hunt him later in the future... > > > > > Many of us don't consider it bad code. I've also always initialized > variables when it was required (and many times when it wasn't) even though > I wasn't forced to do so. A lot of other people do as well. If it's so > important to you, start a program to teach people how you think they should > code. > > > > There a notices, warning and errors to inform you that this shouldn't > have > > been the use case of this feature and you chose to ignore it and now, we > > are simplifying things and making those your errors teach you how to > write > > proper codes in the future, you're objecting.. > > > As has been discussed before, notices are not the same as warnings and > errors. Also, if those things are so wonderful, why can't you use them to > catch the issues you are complaining you can't catch right now? Again, you > are telling me there is something out there which will allow you to force > yourself to write "good code" without forcing me to follow the same > restrictions. Yet, you still feel it's necessary to not use those tools, > and instead modify the entire language so that I am forced to follow what > you deem best practices, even if I don't? > > > > > Why not just stay in PHP 7.x? > > > > Because other features that I want to utilize will also be added in PHP > 8. > > Or were you implying you want hitch-free, no-modification upgrade to PHP 8 > > from PHP 7.0? > > > > I never said that. Here we go again with the "I guess you are against all > BC breaks" nonsense. If BC breaks are required to add new functionality, > or, have a very minimal negative impact, then I don't have a problem with > them. This is not one of those cases. It changes a fundamental aspect of > the language, an aspect that many people actually like, and it doesn't add > any new features to the language, nor is it needed to add any new features > to the language. > > > > If yes, follow the best practices and not suppress error notices. > > > > Just My Opinion > > > > > -- > Chase Peeler > chasepeeler@gmail.com >
  107022
September 12, 2019 21:15 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 4:59 PM Alexandru Pătrănescu <drealecs@gmail.com>
wrote:

> Hi guys, > > > Many of us don't consider it bad code. I've also always initialized > > variables when it was required (and many times when it wasn't) even > though > > I wasn't forced to do so. A lot of other people do as well. If it's so > > important to you, start a program to teach people how you think they > should > > code. > > One problem that needs to be understood is that PHP is used by a lot of > users. > Because it's easy to pick up and you have fast feedback it probably have a > higher percentage of juniors than average. >
I don't think "new developers might do it wrong" is a very compelling argument. We shouldn't handcuff the language because some people might use the flexibility improperly.
> How language was 10 years ago it didn't helped them much in learning and > they did lot of mistakes. Some of those mistakes cost companies lots of > money and, in time, people got to the conclusion that PHP is bad. > This is a very important thing!, Yes you can write working great code in > PHP but it's very easy to write working bad code as well. And it's not > about you and me or the other persons chatting here, it's about the rest of > the world. > > And I don't think we should take away the flexibility that makes PHP great
because some people don't use it correctly. "Billy can't code properly unless the the application crashes whenever he doesn't initialize a variable" isn't any more compelling when it's in the third person than it was in the first person.
> PHP improved on it's bad image in the later years but this needs to > continue. IMO, one thing that we need to also do is to make the language > image better. > With this in mind, I believe the "undefined variable" error will be a step > forward. > > But it won't. People that won't a stricter language aren't going to start
using PHP because it suddenly throws more errors than it used to. As I mentioned before, some non-PHP developers I knew find it appalling that such a massive BC break was even being considered. As much as they don't like the idea of uninitialized variables, the fact that they've been around for 20 years and now there is talk of them making applications crash was much bigger issue. The way we improve PHPs image is we show why the things that make it unique are actually good things, while adding NEW features to the language. No matter how much we try to make PHP like Java, c#, python, etc., it isn't going to entice those developers over to PHP when PHP doesn't offer them anything different than what they already have.
> It's not about if you don't consider it bad code and that apparently the > majority consider it good. > It's that if language wouldn't allow you to write that code it will > benefit the language image and the rest of the PHP comunity. > > Also, I would also like to remind of this: > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md > I think some parts might have been violated multiple time in this thread. > > I can take the hint. This will likely be my last post on the topic. I think
there are few others on this thread that can take up the fight from here on out.
> Regards, > Alex > > > On Thu, Sep 12, 2019 at 10:29 PM Chase Peeler <chasepeeler@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson <oludonsexy@gmail.com> >> wrote: >> >> > On Thu, Sep 12, 2019 at 8:11 PM Michael Babker < >> michael.babker@gmail.com> >> > wrote: >> > >> > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> >> > > wrote: >> > > >> > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < >> > michael.babker@gmail.com> >> > >> wrote: >> > >> >> > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> >> > >>> wrote: >> > >>> >> > >>> > Just a dumb idea, since there clearly is a majority in favor of >> the >> > >>> > change with these warnings and strictness and all that now... Why >> not >> > >>> > making something like an LTS PHP 7.x where all the legacy code >> would >> > >>> > work OK as long as practically possible and 8.x+ would be the >> future >> > >>> > of what the developers want and not what business wants? One who >> > won't >> > >>> > upgrade due to the BC breaks also won't need the new features >> anyway >> > >>> > very realistically. >> > >>> > >> > >>> >> > >>> Please don't tie the notion of LTS with the idea that a new major >> can >> > >>> break >> > >>> BC at will or create larger scale breaks because the previous major >> has >> > >>> extended support. Sooner or later that will end up back at the ++ >> idea >> > >>> and >> > >>> fragmentation encouraged by the language is a bad idea. >> > >>> >> > >> >> > >> Not sure you are really seeing the goal... >> > >> >> > >> Why is LTS not a good idea? >> > >> >> > > >> > > I'm not saying LTS is a bad idea. I'm saying using LTS to justify >> > > shipping larger scale BC breaks, such as the changes suggested in the >> > last >> > > couple of "contentious" RFCs in a major version because "hey, we have >> a >> > LTS >> > > version you can use that until you're ready to deal with the backlog >> of >> > BC >> > > breaks created" is a bad idea. >> > > >> > >> > >> > > For the record, I happen to agree with as these RFCs would have >> minimal >> > > impact on my day-to-day work, but having also been in the role of a >> > > maintainer of open source libraries and applications I also grasp why >> > these >> > > types of changes can be problematic to the ecosystem (both end users >> of >> > > those libraries and applications and the maintainers of them) and >> > wouldn't >> > > jump the gun to ship them without careful consideration. >> > > >> > >> > Most of these changes wouldn't have been problematic to you if the >> language >> > has prevented you from writing what we can now consider bad code, so >> please >> > allow the new PHP developer that newly start using PHP to not follow >> that >> > your path that will/might hunt him later in the future... >> > >> > >> Many of us don't consider it bad code. I've also always initialized >> variables when it was required (and many times when it wasn't) even though >> I wasn't forced to do so. A lot of other people do as well. If it's so >> important to you, start a program to teach people how you think they >> should >> code. >> >> >> > There a notices, warning and errors to inform you that this shouldn't >> have >> > been the use case of this feature and you chose to ignore it and now, we >> > are simplifying things and making those your errors teach you how to >> write >> > proper codes in the future, you're objecting.. >> >> >> As has been discussed before, notices are not the same as warnings and >> errors. Also, if those things are so wonderful, why can't you use them to >> catch the issues you are complaining you can't catch right now? Again, you >> are telling me there is something out there which will allow you to force >> yourself to write "good code" without forcing me to follow the same >> restrictions. Yet, you still feel it's necessary to not use those tools, >> and instead modify the entire language so that I am forced to follow what >> you deem best practices, even if I don't? >> >> >> >> > Why not just stay in PHP 7.x? >> > >> > Because other features that I want to utilize will also be added in PHP >> 8. >> >> Or were you implying you want hitch-free, no-modification upgrade to PHP 8 >> > from PHP 7.0? >> > >> >> I never said that. Here we go again with the "I guess you are against all >> BC breaks" nonsense. If BC breaks are required to add new functionality, >> or, have a very minimal negative impact, then I don't have a problem with >> them. This is not one of those cases. It changes a fundamental aspect of >> the language, an aspect that many people actually like, and it doesn't add >> any new features to the language, nor is it needed to add any new features >> to the language. >> >> >> > If yes, follow the best practices and not suppress error notices. >> > >> > Just My Opinion >> > >> >> >> -- >> Chase Peeler >> chasepeeler@gmail.com >> >
-- Chase Peeler chasepeeler@gmail.com
  107039
September 13, 2019 00:03 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019, 10:15 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> > > On Thu, Sep 12, 2019 at 4:59 PM Alexandru Pătrănescu <drealecs@gmail.com> > wrote: > >> Hi guys, >> >> > Many of us don't consider it bad code. I've also always initialized >> > variables when it was required (and many times when it wasn't) even >> though >> > I wasn't forced to do so. A lot of other people do as well. If it's so >> > important to you, start a program to teach people how you think they >> should >> > code. >> >> One problem that needs to be understood is that PHP is used by a lot of >> users. >> Because it's easy to pick up and you have fast feedback it probably have >> a higher percentage of juniors than average. >> > > I don't think "new developers might do it wrong" is a very compelling > argument. We shouldn't handcuff the language because some people might use > the flexibility improperly. > > >> How language was 10 years ago it didn't helped them much in learning and >> they did lot of mistakes. Some of those mistakes cost companies lots of >> money and, in time, people got to the conclusion that PHP is bad. >> This is a very important thing!, Yes you can write working great code in >> PHP but it's very easy to write working bad code as well. And it's not >> about you and me or the other persons chatting here, it's about the rest of >> the world. >> >> > And I don't think we should take away the flexibility that makes PHP great > because some people don't use it correctly. "Billy can't code properly > unless the the application crashes whenever he doesn't initialize a > variable" isn't any more compelling when it's in the third person than it > was in the first person. >
I hate to see people taking PHP dynamic bug-friendly pattern as great flexibility. Why would something be great and same time be bad? Isn't that a contradiction? PHP is great in flexibility for things like being dynamically typed, fast to launch(major hosts always have it enabled), easier to understand but not for allowing bugs that can cost huge money in the long run. PHP is a very good friendly language when it comes to learning, yet the worst language when it comes to ideology or roadmap. Most companies only prefer PHP to make fast MVP, but as soon as that stage passed, their HR would start searching for developers in other better languages. Check out stackoverflow and see how many buggy questions are asked daily.
> > >> PHP improved on it's bad image in the later years but this needs to >> continue. IMO, one thing that we need to also do is to make the language >> image better. >> With this in mind, I believe the "undefined variable" error will be a >> step forward. >> >> > But it won't. People that won't a stricter language aren't going to start > using PHP because it suddenly throws more errors than it used to. As I > mentioned before, some non-PHP developers I knew find it appalling that > such a massive BC break was even being considered. As much as they don't > like the idea of uninitialized variables, the fact that they've been around > for 20 years and now there is talk of them making applications crash was > much bigger issue. > > The way we improve PHPs image is we show why the things that make it > unique are actually good things, while adding NEW features to the language. > No matter how much we try to make PHP like Java, c#, python, etc., it isn't > going to entice those developers over to PHP when PHP doesn't offer them > anything different than what they already have. > > > >> It's not about if you don't consider it bad code and that apparently the >> majority consider it good. >> It's that if language wouldn't allow you to write that code it will >> benefit the language image and the rest of the PHP comunity. >> >> Also, I would also like to remind of this: >> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md >> I think some parts might have been violated multiple time in this thread.. >> >> > I can take the hint. This will likely be my last post on the topic. I > think there are few others on this thread that can take up the fight from > here on out. > > >> Regards, >> Alex >> >> >> On Thu, Sep 12, 2019 at 10:29 PM Chase Peeler <chasepeeler@gmail.com> >> wrote: >> >>> On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson <oludonsexy@gmail.com> >>> wrote: >>> >>> > On Thu, Sep 12, 2019 at 8:11 PM Michael Babker < >>> michael.babker@gmail.com> >>> > wrote: >>> > >>> > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com >>> > >>> > > wrote: >>> > > >>> > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < >>> > michael.babker@gmail.com> >>> > >> wrote: >>> > >> >>> > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> >>> > >>> wrote: >>> > >>> >>> > >>> > Just a dumb idea, since there clearly is a majority in favor of >>> the >>> > >>> > change with these warnings and strictness and all that now... >>> Why not >>> > >>> > making something like an LTS PHP 7.x where all the legacy code >>> would >>> > >>> > work OK as long as practically possible and 8.x+ would be the >>> future >>> > >>> > of what the developers want and not what business wants? One who >>> > won't >>> > >>> > upgrade due to the BC breaks also won't need the new features >>> anyway >>> > >>> > very realistically. >>> > >>> > >>> > >>> >>> > >>> Please don't tie the notion of LTS with the idea that a new major >>> can >>> > >>> break >>> > >>> BC at will or create larger scale breaks because the previous >>> major has >>> > >>> extended support. Sooner or later that will end up back at the ++ >>> idea >>> > >>> and >>> > >>> fragmentation encouraged by the language is a bad idea. >>> > >>> >>> > >> >>> > >> Not sure you are really seeing the goal... >>> > >> >>> > >> Why is LTS not a good idea? >>> > >> >>> > > >>> > > I'm not saying LTS is a bad idea. I'm saying using LTS to justify >>> > > shipping larger scale BC breaks, such as the changes suggested in the >>> > last >>> > > couple of "contentious" RFCs in a major version because "hey, we >>> have a >>> > LTS >>> > > version you can use that until you're ready to deal with the backlog >>> of >>> > BC >>> > > breaks created" is a bad idea. >>> > > >>> > >>> > >>> > > For the record, I happen to agree with as these RFCs would have >>> minimal >>> > > impact on my day-to-day work, but having also been in the role of a >>> > > maintainer of open source libraries and applications I also grasp why >>> > these >>> > > types of changes can be problematic to the ecosystem (both end users >>> of >>> > > those libraries and applications and the maintainers of them) and >>> > wouldn't >>> > > jump the gun to ship them without careful consideration. >>> > > >>> > >>> > Most of these changes wouldn't have been problematic to you if the >>> language >>> > has prevented you from writing what we can now consider bad code, so >>> please >>> > allow the new PHP developer that newly start using PHP to not follow >>> that >>> > your path that will/might hunt him later in the future... >>> > >>> > >>> Many of us don't consider it bad code. I've also always initialized >>> variables when it was required (and many times when it wasn't) even >>> though >>> I wasn't forced to do so. A lot of other people do as well. If it's so >>> important to you, start a program to teach people how you think they >>> should >>> code. >>> >>> >>> > There a notices, warning and errors to inform you that this shouldn't >>> have >>> > been the use case of this feature and you chose to ignore it and now, >>> we >>> > are simplifying things and making those your errors teach you how to >>> write >>> > proper codes in the future, you're objecting.. >>> >>> >>> As has been discussed before, notices are not the same as warnings and >>> errors. Also, if those things are so wonderful, why can't you use them >>> to >>> catch the issues you are complaining you can't catch right now? Again, >>> you >>> are telling me there is something out there which will allow you to force >>> yourself to write "good code" without forcing me to follow the same >>> restrictions. Yet, you still feel it's necessary to not use those tools, >>> and instead modify the entire language so that I am forced to follow what >>> you deem best practices, even if I don't? >>> >>> >>> >>> > Why not just stay in PHP 7.x? >>> > >>> > Because other features that I want to utilize will also be added in PHP >>> 8. >>> >>> Or were you implying you want hitch-free, no-modification upgrade to PHP >>> 8 >>> > from PHP 7.0? >>> > >>> >>> I never said that. Here we go again with the "I guess you are against all >>> BC breaks" nonsense. If BC breaks are required to add new functionality, >>> or, have a very minimal negative impact, then I don't have a problem with >>> them. This is not one of those cases. It changes a fundamental aspect of >>> the language, an aspect that many people actually like, and it doesn't >>> add >>> any new features to the language, nor is it needed to add any new >>> features >>> to the language. >>> >>> >>> > If yes, follow the best practices and not suppress error notices. >>> > >>> > Just My Opinion >>> > >>> >>> >>> -- >>> Chase Peeler >>> chasepeeler@gmail.com >>> >> > > -- > Chase Peeler > chasepeeler@gmail.com >
  107026
September 12, 2019 21:51 zeev@php.net (Zeev Suraski)
On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu <drealecs@gmail.com>
wrote:

> Also, I would also like to remind of this: > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md > I think some parts might have been violated multiple time in this thread.
As was already pointed out in a different thread recently, the ones you seem to refer to are guidelines - or rather 'hints'. They cannot be 'violated'. It doesn't mean it doesn't make sense to follow them - but there's a reason they're only hints, and not rules. Zeev
  107038
September 12, 2019 23:56 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
Hi Zeev,

I just reminded the rules so everyone remembers we have them for this
mailing list.
I actually was not referring to hints 1 and 2, even if I still believe they
are good hints to follow in order to have the discussion more productive
and respectful to everyone.

I was actually referring to rules 1 and 2 that I suspect might have been
violated.
Of course, the evaluation if they broke it or not would be first of all
(and best of all) done by each person individually.
I really hope everyone is self-evaluating every now and then.

Regards,
Alex


On Fri, Sep 13, 2019 at 12:51 AM Zeev Suraski <zeev@php.net> wrote:

> > > On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu <drealecs@gmail.com> > wrote: > >> Also, I would also like to remind of this: >> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md >> I think some parts might have been violated multiple time in this thread.. > > > As was already pointed out in a different thread recently, the ones you > seem to refer to are guidelines - or rather 'hints'. They cannot be > 'violated'. It doesn't mean it doesn't make sense to follow them - but > there's a reason they're only hints, and not rules. > > Zeev > >
  107012
September 12, 2019 19:15 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker babker@gmail.com> > wrote: > > > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> > wrote: > > > > > Just a dumb idea, since there clearly is a majority in favor of the > > > change with these warnings and strictness and all that now... Why not > > > making something like an LTS PHP 7.x where all the legacy code would > > > work OK as long as practically possible and 8.x+ would be the future > > > of what the developers want and not what business wants? One who won't > > > upgrade due to the BC breaks also won't need the new features anyway > > > very realistically. > > > > > > > Please don't tie the notion of LTS with the idea that a new major can > break > > BC at will or create larger scale breaks because the previous major has > > extended support. Sooner or later that will end up back at the ++ idea > and > > fragmentation encouraged by the language is a bad idea. > > > > Not sure you are really seeing the goal... > > Why is LTS not a good idea? > And, if the majority want this or that, can we just blow everything into > full dictatorship where i can host my fork of PHP doing uncountable > unwanted things i can call it..? > > Any which way, i think the majority of us are tired of writing bad codes, > but since the language is allowing it we don't have choices than to spend > some hours or weeks later debugging the wrong or right line we did that > last "big mistake", who knows there might be another line smiling coz i > haven't detected it... >
I can write good code without sacrificing the flexibility provided by PHP. Don't force ME to write code a specific way because you aren't disciplined enough to not write bad code without the compiler forcing you to do things a certain way. Of all of the justifications for this RFC I've heard, "I can't stop writing bad code as long as I'm allowed to" has to be the worst. -- Chase Peeler chasepeeler@gmail.com
  107014
September 12, 2019 19:19 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 8:15 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> > > On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson <oludonsexy@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker babker@gmail.com> >> wrote: >> >> > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> >> wrote: >> > >> > > Just a dumb idea, since there clearly is a majority in favor of the >> > > change with these warnings and strictness and all that now... Why not >> > > making something like an LTS PHP 7.x where all the legacy code would >> > > work OK as long as practically possible and 8.x+ would be the future >> > > of what the developers want and not what business wants? One who won't >> > > upgrade due to the BC breaks also won't need the new features anyway >> > > very realistically. >> > > >> > >> > Please don't tie the notion of LTS with the idea that a new major can >> break >> > BC at will or create larger scale breaks because the previous major has >> > extended support. Sooner or later that will end up back at the ++ idea >> and >> > fragmentation encouraged by the language is a bad idea. >> > >> >> Not sure you are really seeing the goal... >> >> Why is LTS not a good idea? >> And, if the majority want this or that, can we just blow everything into >> full dictatorship where i can host my fork of PHP doing uncountable >> unwanted things i can call it..? >> >> Any which way, i think the majority of us are tired of writing bad codes, >> but since the language is allowing it we don't have choices than to spend >> some hours or weeks later debugging the wrong or right line we did that >> last "big mistake", who knows there might be another line smiling coz i >> haven't detected it... >> > > I can write good code without sacrificing the flexibility provided by PHP. > Don't force ME to write code a specific way because you aren't disciplined > enough to not write bad code without the compiler forcing you to do things > a certain way. > > Of all of the justifications for this RFC I've heard, "I can't stop > writing bad code as long as I'm allowed to" has to be the worst. > > Yea, that's just one of the popular reasons, there are more if you go on Stack Overflow and see what this dynamism(my foot) has caused to real-world
codes and fortunes that has been lost due to it(Which i'm also a testimony to the fact).
> -- > Chase Peeler > chasepeeler@gmail.com >
  107008
September 12, 2019 19:04 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 2:51 PM Peter Kokot <peterkokot@gmail.com> wrote:

> On Thu, 12 Sep 2019 at 20:35, Zeev Suraski <zeev@php.net> wrote: > > > > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote: > > > > > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > > with > > > > such changes then? The answer is simple. We don't. We don't have > to > > > have > > > > them either - the fundamental language behaviors are here to stay. > > > > > > But we still need processes to define which are the "fundamental > > > language behaviours". And as change is the only constant in > > > software-development, these "fundamental language behaviours" might, > can > > > and probably should be changeable. I'm not saying they need to change, > > > but it has to be possible to change them. Otherwise we would still > > > program business-logic in C as that was Rasmus' fundamental idea IIRC > > > (Correct me if I'm wrong) > > > > > > > You're right. The thing is this - as I said, the RFC process was > designed > > to address additions to the language - as is implied in numerous places > > (both the part I quoted from the RFC itself, as well as elements in RFC > > template as well as the RFC howto). It was never meant to handle > > deprecations - mainly because we simply weren't doing much of that back > in > > the days where it was introduced. It was meant to resolve the issue at > > hand at the time (and in the years leading up to it) - which is a formal > > way to agree on which features make it in and which ones don't. > > Now, over the years (and more and more as of late) - it started being > used > > for deprecations. But these deprecations have become more and more > extreme > > recently in terms of their impact. Of course I do think deprecations > > should be allowed, like in any other language. I do think we need to > have > > a higher bar for them in general (both in terms of a clear benefits and > > required majority - as is implied in the Voting RFC) - but since we've > > grown used to using 2/3 for them - and given the pro-deprecation bias of > > the current composition of internals@ - I also realize it will be tough > to > > do. But when dealing with deprecation proposals that are likely to > effect > > a very sizable subset of our userbase and codebase, and deal with some of > > the most basic building blocks of the language - we simply can't start > > using the same process. We never have in the past (none of the > > deprecations we voted on since 2013 comes even remotely close to the > level > > of impact of the two proposals that have been put forward to a vote in > the > > recent couple of months, and the more recent one clearly far outdoes the > > prior one in terms of impact). > > > > Should we have 'woken up' many years ago when we started using the Voting > > RFC for deprecations it wasn't meant to handle? Probably. It would have > > been much easier to install a new mechanism. But it doesn't mean we > should > > repeat the same mistake, now that it begins to be used to deprecate > > mainstream language behaviors. > > > > In terms of telling one from the other - right now, I'm afraid it's a bit > > like some other things that fall into the category of 'you know it when > you > > see it'. I think few can deny that far-reaching effect of changing how > > variables behave in a language, whether they think it's a change for the > > better or for the worse. But I think it *may* be possible to formally > > define. These are just random thoughts at this point - but we could > have a > > set of apps/frameworks that we use as a testing bed to check the level of > > impact of a certain proposal. If that impact is above a certain > threshold > > - it will be considered fundamental. Of course, things like WordPress, > > Joomla and MediaWiki would have to be a part of that - not just modern > > frameworks. It's still not ideal since it doesn't account for the > majority > > of PHP code out there which isn't Open Source - but it may be a start. > > There may be other ways - such as letting folks run that analysis on > their > > own code behind the firewall and report results back. > > > > But there's also a simpler solution to this. This 'can of worms' as > Arvids > > called it, wouldn't have been opened had we agreed to focus on extending > > PHP instead of trying to replace it with something else. This is what > the > > RFC process was meant to facilitate. It still can, but for that, we need > > to change the dynamics from a zero-sum game to a goal of a win/win. > Yes, I > > realize that I'm sounding like a broken record. But call me naive - I'm > > still hoping that given it obviously can be done from a technical > > perspective (in a wide variety of ways too) - we can find the good will > to > > do it from a human perspective. > > > > Zeev > > > > > > > > > Just a dumb idea, since there clearly is a majority in favor of the > change with these warnings and strictness and all that now... Why not > making something like an LTS PHP 7.x where all the legacy code would > work OK as long as practically possible and 8.x+ would be the future > of what the developers want and not what business wants? One who won't > upgrade due to the BC breaks also won't need the new features anyway > very realistically. > > Someone that has a lot of uninitialized variables could definitely take
advantage of features like enums and union types (just to name a few). If there were actually new, useful features that were dependent on such a change, then I'd be much more open to the idea, if not outright in favor of it. However, there aren't any new and useful features that are dependent on the errors being thrown for uninitialized variables.
> Microsoft, Zend, and Red Hat have been showing that this is actually > possible. How smart this is for the PHP progress is another story, but > for the business it might be good to think about this also I guess: > https://github.com/microsoft/php-src/releases > > So, to make some sort of a milestone with some of the versions - > either 8 or 9 or something. > > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  107076
September 13, 2019 12:19 remi@php.net (Remi Collet)
Le 12/09/2019 à 20:51, Peter Kokot a écrit :

> Just a dumb idea, since there clearly is a majority in favor of the > change with these warnings and strictness and all that now... Why not > making something like an LTS PHP 7.x where all the legacy code would > work OK as long as practically possible and 8.x+ would be the future > of what the developers want and not what business wants? One who won't > upgrade due to the BC breaks also won't need the new features anyway > very realistically. > > Microsoft, Zend, and Red Hat have been showing that this is actually > possible. How smart this is for the PHP progress is another story, but > for the business it might be good to think about this also I guess: > https://github.com/microsoft/php-src/releases > > So, to make some sort of a milestone with some of the versions - > either 8 or 9 or something.
This is chicken and eggs problem "Maintained because used" or "used because maintained" ? PHP 7 was a very good version, with good BC, and speed of adoption is quite good. But some users still old 5.x From download of my repo [1] In January, ~35% for 5.6 In August, down to ~28% IMHO, more BC breaks will mean more time to adapt code and more slow adoption by users. So Yes, we'll need a longer support time for 7.4, as we have extended support for 5.6 by 1 year). Perhaps more will be needed for 7.4. But yes, we are allowed to change things and dream of a perfect language, like Perl 6... Remi [1] this are only numbers... from about 5k RPM download per day, and probably artificially bigger for EOL versions, because I'm the only repo to provide them.
  107009
September 12, 2019 19:06 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 2:35 PM Zeev Suraski <zeev@php.net> wrote:

> On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote: > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > with > > > such changes then? The answer is simple. We don't. We don't have to > > have > > > them either - the fundamental language behaviors are here to stay. > > > > But we still need processes to define which are the "fundamental > > language behaviours". And as change is the only constant in > > software-development, these "fundamental language behaviours" might, can > > and probably should be changeable. I'm not saying they need to change, > > but it has to be possible to change them. Otherwise we would still > > program business-logic in C as that was Rasmus' fundamental idea IIRC > > (Correct me if I'm wrong) > > > > You're right. The thing is this - as I said, the RFC process was designed > to address additions to the language - as is implied in numerous places > (both the part I quoted from the RFC itself, as well as elements in RFC > template as well as the RFC howto). It was never meant to handle > deprecations - mainly because we simply weren't doing much of that back in > the days where it was introduced. It was meant to resolve the issue at > hand at the time (and in the years leading up to it) - which is a formal > way to agree on which features make it in and which ones don't. > Now, over the years (and more and more as of late) - it started being used > for deprecations. But these deprecations have become more and more extreme > recently in terms of their impact. Of course I do think deprecations > should be allowed, like in any other language. I do think we need to have > a higher bar for them in general (both in terms of a clear benefits and > required majority - as is implied in the Voting RFC) - but since we've > grown used to using 2/3 for them - and given the pro-deprecation bias of > the current composition of internals@ - I also realize it will be tough to > do. But when dealing with deprecation proposals that are likely to effect > a very sizable subset of our userbase and codebase, and deal with some of > the most basic building blocks of the language - we simply can't start > using the same process. We never have in the past (none of the > deprecations we voted on since 2013 comes even remotely close to the level > of impact of the two proposals that have been put forward to a vote in the > recent couple of months, and the more recent one clearly far outdoes the > prior one in terms of impact). > > Should we have 'woken up' many years ago when we started using the Voting > RFC for deprecations it wasn't meant to handle? Probably. It would have > been much easier to install a new mechanism. But it doesn't mean we should > repeat the same mistake, now that it begins to be used to deprecate > mainstream language behaviors. > > In terms of telling one from the other - right now, I'm afraid it's a bit > like some other things that fall into the category of 'you know it when you > see it'. I think few can deny that far-reaching effect of changing how > variables behave in a language, whether they think it's a change for the > better or for the worse. But I think it *may* be possible to formally > define. These are just random thoughts at this point - but we could have a > set of apps/frameworks that we use as a testing bed to check the level of > impact of a certain proposal. If that impact is above a certain threshold > - it will be considered fundamental. Of course, things like WordPress, > Joomla and MediaWiki would have to be a part of that - not just modern > frameworks. It's still not ideal since it doesn't account for the majority > of PHP code out there which isn't Open Source - but it may be a start. > There may be other ways - such as letting folks run that analysis on their > own code behind the firewall and report results back. > > But there's also a simpler solution to this. This 'can of worms' as Arvids > called it, wouldn't have been opened had we agreed to focus on extending > PHP instead of trying to replace it with something else. This is what the > RFC process was meant to facilitate. It still can, but for that, we need > to change the dynamics from a zero-sum game to a goal of a win/win. Yes, I > realize that I'm sounding like a broken record. But call me naive - I'm > still hoping that given it obviously can be done from a technical > perspective (in a wide variety of ways too) - we can find the good will to > do it from a human perspective. > > Exactly. I think it's telling that the majority of the rebuttals to
arguments against the RFC are to claim that we're against moving the language forward, against BC breaks, etc. That couldn't be further from the truth. We do want to move the language forward. We want do that by adding to the language, and not changing it into an entirely different language.
> Zeev > > > > >
-- Chase Peeler chasepeeler@gmail.com