# Changing fundamental language behaviors - Thread: https://externals.io/message/106963 - Original archive: https://news-web.php.net/php.internals/106963 - Started by Zeev Suraski on 2019-09-12T14:44:03+00:00 - Messages: 75 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/106963.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #106963 — Zeev Suraski — 2019-09-12T14:44:03+00:00 URL: https://externals.io/message/106963#106963 I was really really hoping that we will avert having to dive into this and instead go for the alternative solution that was proposed of changing default php.ini error levels. But since the RFC went on to a vote - we need to make something clear. The RFC process was never, ever meant to handle fundamental changes to the language. It was meant to deal predominantly with additions to the language, as can be inferred from numerous parts in the phrasing. As I mentioned in the past - it wasn't even intended to deal with simpler deprecations, but it appears that the cat is out of the bag on this one. However, the fact the cat is out, doesn't mean we'll let a tiger waltz out of the same bag. Using the RFC to deprecate fundamental behaviors of the language - such as how the language deals with undefined variables - is simply off the table. You may be wondering, in that case, what processes do we have to deal with such changes then? The answer is simple. We don't. We don't have to have them either - the fundamental language behaviors are here to stay. Deprecating the ability to rely on the expected default value of uninitialized variables falls squarely in that category. Reclassifying a notice to a warning is a possibility - people's code will still run, and they'll be able to continue using these behaviors going forward as well if they want to (perhaps with minor tweaks to error reporting levels). Turning a notice to an error isn't reclassifying an error level. It's deprecating a behavior - and we're not talking about some esoteric extension, but a documented, well-defined, fundamental behavior of the language for over two decades. The fact many of you think it's horrible does not change that. Deprecating such fundamentals is simply outside of the mandate of internals@, regardless of whatever majority appears to exist in favor of it at a given time. Similarly - adding typed variables - is certainly a future option. Changing PHP to require typed variables (without opting in) - is well outside of the internals@ mandate. For areas like that - our options are either doing nothing, or providing opt-in mechanisms to cater to stricter-loving audiences. I'm all for the 2nd option, but there is no 3rd. Zeev --- ## #106965 — Dan Ackroyd — 2019-09-12T14:52:36+00:00 URL: https://externals.io/message/106963#106965 · In reply to: #106963 > > The RFC process was never, ever meant to handle fundamental changes to the > language. The only appropriate response to this is "lolwat?". You keep making up rules...that don't exist. You can't expect people to suddenly stop using RFCs to change the language just because you say so. Please stop this behaviour. It's really not appropriate. sincerely Dan Ack --- ## #106966 — Marco Pivetta — 2019-09-12T14:58:36+00:00 URL: https://externals.io/message/106963#106966 · In reply to: #106963 Hi Zeev, > I was really really hoping that we will avert having to dive into this and > instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we > need > to make something clear. > > > > The RFC process was never, ever meant to handle fundamental changes to the > language. It was meant to deal predominantly with additions to the > language, as can be inferred from numerous parts in the phrasing. As I > mentioned in the past - it wasn't even intended to deal with simpler > deprecations, but it appears that the cat is out of the bag on this one. > However, the fact the cat is out, doesn't mean we'll let a tiger waltz out > of the same bag. Using the RFC to deprecate fundamental behaviors of the > language - such as how the language deals with undefined variables - is > simply off the table. > > > > You may be wondering, in that case, what processes do we have to deal with > such changes then? The answer is simple. We don't. We don't have to have > them either - the fundamental language behaviors are here to stay. > > Deprecating the ability to rely on the expected default value of > uninitialized variables falls squarely in that category. > > > > Reclassifying a notice to a warning is a possibility - people's code will > still run, and they'll be able to continue using these behaviors going > forward as well if they want to (perhaps with minor tweaks to error > reporting levels). Turning a notice to an error isn't reclassifying an > error level. It's deprecating a behavior - and we're not talking about > some > esoteric extension, but a documented, well-defined, fundamental behavior of > the language for over two decades. The fact many of you think it's > horrible > does not change that. Deprecating such fundamentals is simply outside of > the mandate of internals@, regardless of whatever majority appears to > exist > in favor of it at a given time. > > > > Similarly - adding typed variables - is certainly a future option. > Changing > PHP to require typed variables (without opting in) - is well outside of the > internals@ mandate. > > > > For areas like that - our options are either doing nothing, or providing > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > 2nd option, but there is no 3rd. > If you want to have an authoritative say on what the RFC process is for or not, please start a new RFC about it: your mail is just straight out inappropriate. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #106967 — Arvids Godjuks — 2019-09-12T14:58:56+00:00 URL: https://externals.io/message/106963#106967 · In reply to: #106965 чт, 12 сент. 2019 г. в 16:53, Dan Ackroyd : > > > […] > the > > […] > > The only appropriate response to this is "lolwat?". > > You keep making up rules...that don't exist. You can't expect people > to suddenly stop using RFCs to change the language just because you > say so. > > Please stop this behaviour. It's really not appropriate. > > sincerely > Dan > Ack > > -- > > > > Agree and support, but I mostly want to convey this to everyone: For once, let's not knee-jerk post reply. Let's take a day to stew on this, formulate the though and express it. I will do the same, cause I really want to knee-jerk here, but we know how that ended in recent months and issues it caused. So let's take the opportunity to voice our opinions in an orderly manner since Zeev basically opened this can of worms and I honestly do not see this going well. -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius --- ## #106970 — Olumide Samson — 2019-09-12T15:02:37+00:00 URL: https://externals.io/message/106963#106970 · In reply to: #106965 You first me on that reply Dan, I guess I should just say "the naysayers are back", I can see their footprint all around. The RFC is Request for Comment on any changes, is there an explicit or implicit mention about what kind of proposed changes can be made? Mr/Mrs Zeev are you for PHP or against it? I know you are one of the authors of Zend Engine, but please follow the rules and don't make rules simply because something is going the way you don't want it to. That's why there's this called "vote". > > > […] > the > > […] > > The only appropriate response to this is "lolwat?". > > You keep making up rules...that don't exist. You can't expect people > to suddenly stop using RFCs to change the language just because you > say so. > > Please stop this behaviour. It's really not appropriate. > > sincerely > Dan > Ack --- ## #106972 — Zeev Suraski — 2019-09-12T15:11:18+00:00 URL: https://externals.io/message/106963#106972 · In reply to: #106966 > -----Original Message----- > From: Marco Pivetta > Sent: Thursday, September 12, 2019 5:59 PM > To: Zeev Suraski > Cc: PHP Internals List > 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 --- ## #106973 — Chase Peeler — 2019-09-12T15:11:36+00:00 URL: https://externals.io/message/106963#106973 > > > […] > Changing > > […] > the > > […] > > > While I am not sure your tone will be well received by your target > audience, I just wanted to say I tend to agree. > > My thoughts as well. > Breaking BC here does not seem to bring much. If there are cases where > enforcing strictness might allow better JIT for example, then I could > see the case being made. But simply turning working code into fatally > failing code isn't progress. > > Yes! > I know I have a bunch of old stuff running which tends to litter the > error logs with notices, and I don't have time to go fix them so I > ignore because it's fine and it works. > > Can't make that argument. Be prepared to be told how easy it should be for you to fix it, or, how it's technical debt (ignoring the fact that it's not technical debt currently, since there is nothing wrong with what was written) and you're just making things worse by not taking care of it. > For new projects, what I do, and what I am pretty sure 99% of the > "strict camp" does is essentially boiling down to: > > set_error_handler(function () { throw new \RuntimeException(); }); > > That's our global strictness flag right there. It's been available for > ages. I don't see why we need to take something away from others to make > such an easy workaround a little less needed. Especially as I don't > imagine we will drop the error handlers. I sure will keep mine around to > keep failing warnings etc as hard fatals. > > So what do we gain exactly? > > That's the argument I've been making all along. There are so many ways to accomplish what has been proposed without forcing it on those that don't want it. It's not required in order to add new features to the language. It doesn't make the language perform better, either. It's also not taking away something that is definitely a negative feature. It's taking away something that many view as a positive feature of the language. If there was no way to achieve the intended results without making the change, I might be more sympathetic to making it. But there is. Whether it's an error handler like you mentioned above, stricter code reviews, public shaming for anyone that doesn't initialize their variables, or any of the myriad of other options. > Best, > Jordi > > -- > > Jordi Boggiano > @seldaek - https://seld.be > > -- > > > > -- Chase Peeler chasepeeler@gmail.com --- ## #106974 — Zeev Suraski — 2019-09-12T15:27:58+00:00 URL: https://externals.io/message/106963#106974 · In reply to: #106970 > -----Original Message----- > From: Olumide Samson > Sent: Thursday, September 12, 2019 6:03 PM > To: Dan Ackroyd > Cc: Zeev Suraski ; PHP internals > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > The RFC is Request for Comment on any changes, is there an explicit or implicit > mention about what kind of proposed changes can be made? While the Voting RFC was probably one of my worst creations - because it's was so laconic and lacking (although it still probably did more good for PHP than bad) - yes - there's a strong implication as to what it's meant to deal with and what it isn't meant to deal with. Here's what the Voting RFC said: "Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible" I understand this isn't written black-on-white that you can't deprecate a fundamental language behavior. But it's clear that "having to win a 2/3 vote" isn't quite the definition of "irreversible". The idea behind the 2/3 requirement (a number that I came up with) was to ensure that the motivation to undo that addition/change will likely remain very low in the years following the vote on the RFC. Why? Because once it's in - it's in. It cannot be taken out. It's irreversible. So no, a 2/3 vote does not get us the mandate to deprecate a fundamental language behavior. It's basically a reasonably high bar to add something to the language - given that we know that once we add it, we cannot take it away. Nothing more, nothing less. Zeev --- ## #106977 — Matthew Brown — 2019-09-12T16:16:35+00:00 URL: https://externals.io/message/106963#106977 · In reply to: #106963 Without your contributions in the early 2000s, PHP likely would not enjoy the popularity it does today. But I don't think that gives you veto power over the entire process. You haven't made any significant contributions to the codebase in over a decade, and yet the language has still gained many more users in that time frame, with some fairly major backwards-incompatible changes along the way. I think you have to come to terms with the fact that today you are a single vote in this process — though you are, of course, free to write your own RFCs. Best wishes, Matt > I was really really hoping that we will avert having to dive into this and > instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we > need > to make something clear. > > > > The RFC process was never, ever meant to handle fundamental changes to the > language. It was meant to deal predominantly with additions to the > language, as can be inferred from numerous parts in the phrasing. As I > mentioned in the past - it wasn't even intended to deal with simpler > deprecations, but it appears that the cat is out of the bag on this one. > However, the fact the cat is out, doesn't mean we'll let a tiger waltz out > of the same bag. Using the RFC to deprecate fundamental behaviors of the > language - such as how the language deals with undefined variables - is > simply off the table. > > > > You may be wondering, in that case, what processes do we have to deal with > such changes then? The answer is simple. We don't. We don't have to have > them either - the fundamental language behaviors are here to stay. > > Deprecating the ability to rely on the expected default value of > uninitialized variables falls squarely in that category. > > > > Reclassifying a notice to a warning is a possibility - people's code will > still run, and they'll be able to continue using these behaviors going > forward as well if they want to (perhaps with minor tweaks to error > reporting levels). Turning a notice to an error isn't reclassifying an > error level. It's deprecating a behavior - and we're not talking about > some > esoteric extension, but a documented, well-defined, fundamental behavior of > the language for over two decades. The fact many of you think it's > horrible > does not change that. Deprecating such fundamentals is simply outside of > the mandate of internals@, regardless of whatever majority appears to > exist > in favor of it at a given time. > > > > Similarly - adding typed variables - is certainly a future option. > Changing > PHP to require typed variables (without opting in) - is well outside of the > internals@ mandate. > > > > For areas like that - our options are either doing nothing, or providing > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > 2nd option, but there is no 3rd. > > > > Zeev --- ## #106978 — Morgan Breden — 2019-09-12T16:18:19+00:00 URL: https://externals.io/message/106963#106978 · In reply to: #106972 > While I realize my email is unpleasant for many to read, it's in the context of an RFC that attempts to do something that is strictly inappropriate and out of the question. Stating the fact, that the RFC process was never meant to allow this to be done, is a statement of fact. [...] > There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or radically change them. [...] > But those who dream of simply changing PHP into a stricter language step by step should understand that this is simply not going to be happen. Not now, not ever. Zeev, "strictly inappropriate and out of the question" seems like a statement of opinion to me. While I personally agree with your standpoint on changing this fundamental behavior, your response here seems out of left field. Furthermore, statements like "we do not get to deprecate or radically change them" and "this is simply not going to happen" are a wholly inappropriate response to *any* effort. I respect your vast contributions to the language and your (usually) level-headed stances on this mailing list, but you are not the grand czar of PHP and I don't believe that hard line is yours to make. Declaring such a thing reads to me like a spit in the face of everyone who contributes to the language and to the concept of a community-driven open source project to begin with. Over the past few years the movement to push PHP into more modern concepts has explosively grown in popularity and your resistance to the more rapid and drastic portions of it is understandable, if nothing else. However, using your bully pulpit to insist that things you don't like can't be done leaves a very sour taste in my mouth. If such limits exist, they should be clear and codified - not something that exists in the mind of you and whoever else only to be brought up when someone wants to breach them. > > > > […] > or not, > > […] > 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 --- ## #106979 — Andreas Heigl — 2019-09-12T16:39:12+00:00 URL: https://externals.io/message/106963#106979 · In reply to: #106977 Hey Zeev. I'm not that deep into @internals and might not get the subtle subtext. English is not my native tongue so I might phrase things in a way that doesn't transport the whole meaning of my thoughts. But your Mail really left me curious: > I was really really hoping that we will avert having to dive into this and > instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we > need > to make something clear. > > > > The RFC process was never, ever meant to handle fundamental changes to the > language. It was meant to deal predominantly with additions to the > language, as can be inferred from numerous parts in the phrasing. As I > mentioned in the past - it wasn't even intended to deal with simpler > deprecations, but it appears that the cat is out of the bag on this one. > However, the fact the cat is out, doesn't mean we'll let a tiger waltz out > of the same bag. Using the RFC to deprecate fundamental behaviors of the > language - such as how the language deals with undefined variables - is > simply off the table. Given the fact that you have the authority to say so, what actually *is* the process then to make "fundamental changes to the language"? > > > > You may be wondering, in that case, what processes do we have to deal with > such changes then? The answer is simple. We don't. We don't have to have > them either - the fundamental language behaviors are here to stay. But we still need processes to define which are the "fundamental language behaviours". And as change is the only constant in software-development, these "fundamental language behaviours" might, can and probably should be changeable. I'm not saying they need to change, but it has to be possible to change them. Otherwise we would still program business-logic in C as that was Rasmus' fundamental idea IIRC (Correct me if I'm wrong) > > Deprecating the ability to rely on the expected default value of > uninitialized variables falls squarely in that category. > > > > Reclassifying a notice to a warning is a possibility - people's code will > still run, and they'll be able to continue using these behaviors going > forward as well if they want to (perhaps with minor tweaks to error > reporting levels). Turning a notice to an error isn't reclassifying an > error level. It's deprecating a behavior - and we're not talking about > some > esoteric extension, but a documented, well-defined, fundamental behavior of > the language for over two decades. The fact many of you think it's > horrible > does not change that. Deprecating such fundamentals is simply outside of > the mandate of internals@, regardless of whatever majority appears to > exist > in favor of it at a given time. > > > > Similarly - adding typed variables - is certainly a future option. > Changing > PHP to require typed variables (without opting in) - is well outside of the > internals@ mandate. So tell us, what is *insight* the @internals mandate. And who has the mandate to change the things @internals does not have the mandate to. From what i see you tell us (@internals) "You're not allowed to do so, but I will not tell you who *is* allowed." So for me that raises two main questions: 1. Who then has the mandate to do so? 2. By what authority are you making this statement? I'm looking forward to your answers. Cheers Andreas > > > > For areas like that - our options are either doing nothing, or providing > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > 2nd option, but there is no 3rd. > > > > Zeev -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --- ## #106980 — Scott Arciszewski — 2019-09-12T16:51:33+00:00 URL: https://externals.io/message/106963#106980 · In reply to: #106972 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 Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises > > > > > […] > > 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 --- ## #106981 — Chase Peeler — 2019-09-12T16:56:13+00:00 URL: https://externals.io/message/106963#106981 · In reply to: #106980 On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski wrote: > I'd like to weigh in as a voice of reason here. > > > […] > in PHP. > > This part might be reasonable. > > > […] > 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 > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises > > > > > […] > for or not, > > […] > inappropriate. > > […] > 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. > > […] > 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. > > […] > 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. > > […] > 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. > > […] > 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. > > […] > > -- > > > > -- Chase Peeler chasepeeler@gmail.com --- ## #106982 — Scott Arciszewski — 2019-09-12T17:02:56+00:00 URL: https://externals.io/message/106963#106982 · In reply to: #106981 Apologies for my semantic imprecision. I hope the intent of my email remains clear. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises > > > > > > […] > > 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. > > > […] > > > -- > Chase Peeler > chasepeeler@gmail.com --- ## #106983 — Matthew Brown — 2019-09-12T17:05:19+00:00 URL: https://externals.io/message/106963#106983 · In reply to: #106981 > > 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 — Chase Peeler — 2019-09-12T17:22:19+00:00 URL: https://externals.io/message/106963#106985 · In reply to: #106983 On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown 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 — Matthew Brown — 2019-09-12T17:33:43+00:00 URL: https://externals.io/message/106963#106986 · In reply to: #106985 > > 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. --- ## #106987 — Lynn — 2019-09-12T17:37:11+00:00 URL: https://externals.io/message/106963#106987 · In reply to: #106985 > 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 --- ## #106988 — Olumide Samson — 2019-09-12T17:39:34+00:00 URL: https://externals.io/message/106963#106988 · In reply to: #106985 > On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown > wrote: > > > […] > like > > […] > 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)... --- ## #106989 — Chase Peeler — 2019-09-12T17:41:10+00:00 URL: https://externals.io/message/106963#106989 · In reply to: #106986 On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown wrote: > What if Java suddenly said that all properties are suddenly private, and > > […] > > 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 > > […] > > > 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 --- ## #106990 — Chase Peeler — 2019-09-12T17:51:59+00:00 URL: https://externals.io/message/106963#106990 · In reply to: #106988 > > > On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler > wrote: > > > […] > > 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 > > […] > > 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 > > […] > > 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 > > […] > 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. > > > […] > 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 --- ## #106991 — Chase Peeler — 2019-09-12T17:54:28+00:00 URL: https://externals.io/message/106963#106991 · In reply to: #106986 On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown wrote: > What if Java suddenly said that all properties are suddenly private, and > > […] > > 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 > > […] > > > 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 --- ## #106992 — Stephen Reay — 2019-09-12T17:57:50+00:00 URL: https://externals.io/message/106963#106992 · In reply to: #106989 > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown > wrote: > > > […] > > 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? --- ## #106993 — Olumide Samson — 2019-09-12T17:58:38+00:00 URL: https://externals.io/message/106963#106993 · In reply to: #106991 > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown > wrote: > > > […] > after > > […] > 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) > > > […] > > -- > Chase Peeler > chasepeeler@gmail.com --- ## #106994 — Mike Schinkel — 2019-09-12T17:58:58+00:00 URL: https://externals.io/message/106963#106994 · In reply to: #106987 > > > > > > […] > > 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 --- Next page: https://externals.io/message/106963.md?page=2