Re: Future stability of PHP?

From: Date: Mon, 10 Apr 2023 18:29:58 +0000
Subject: Re: Future stability of PHP?
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-119870@lists.php.net to get a copy of this message
On Mon, Apr 10, 2023, 1:17 PM Pierre Joye <pierre.php@gmail.com> wrote: > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <stephan.soller@helionweb.de> > wrote: > > > Hello, > > > > I'm sorry if this isn't the correct mailing list for that discussion but > I > > couldn't find a more appropriate one where people actually know how the > > wind is > > blowing. > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > deprecations and fatal errors spooked me a bit (details below if you're > > interested). That got me wondering about the long-term stability of PHP > > (as in > > language and API breaks) and I looked at the RFCs. I got the impression > > that > > static typing has a lot of traction now and I have no idea of what the > > fallout > > might be of changing a dynamically typed language into a statically > > typed one. > > > I keep reading this in multiple languages, pr even more frameworks. > > I understand agency work, managers pushing new features instead of a > cleaning some legacy. > > however years of ignoring deprecation notices (very few were introduced > right before 8.0). > > Most of them could have been fixed within a couple of hours in any code > base, if they had tests. > > I would suggest, very very nicely, to review and rethink the development > flows of these projects instead of asking php to freeze. > > best, > Pierre > I resent the sentiment of "if your code or development process was exactly like mine you wouldn't be here complaining" and I believe nobody is asking PHP to freeze. Not everyone has the ability to fix every deprecation within a couple of hours and not everyone has tests. Yes, we get it, it's common knowledge nowadays that code without test is unmanageable, but if you inherited a 15 year old codebase developed by multiple developers in a start-up mentality producing code faster than they could actually plan for and with no tests, its going to take some time to clean that up and if I take longer than you would, does it mean I matter less as a PHP user? PHP 8 is pretty great to work with and a lot better than previous versions, but there was no opt-in aspect to a lot of PHP breakages. All that we're asking here is for a bit more forgiveness to existing code that was developed 2 decades ago by a complete different generation and still need to run today while we clean it up. >

« previous php.internals (#119870) next »