Re: [PHP-DEV] Changing fundamental language behaviors

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