# Future stability of PHP? - Thread: https://externals.io/message/119834 - Original archive: https://news-web.php.net/php.internals/119834 - Started by Stephan Soller on 2023-04-08T18:36:52+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/119834.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 --- ## #119834 — Stephan Soller — 2023-04-08T18:36:52+00:00 URL: https://externals.io/message/119834#119834 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. Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled across the language evolution RFC proposals but it seems that approach was abandoned. Is there a way to tell which APIs and language features will be stable and which might get changed or removed in the future? That way I could restrict myself to a stable subset for long-running projects (5 to 10 years). But I realize that such guarantees are difficult (or contra productive) when a language is in flux and I can understand if no one wants to do something like that. Some of my projects run for 5 to 10 years, in one case even 20 years. Usually without or with very little code changes. My usual tool set for web projects like that is plain PHP, HTML, CSS and JS. Everything without any frameworks or unnecessary libraries and kept as simple as possible. If possible I just use builtin and stable APIs and usually end up without any or with just one or two dependencies (e.g. PDF generation). This isn't pretty and I end up trading a bit of productivity for long-term stability. I know this is quite an unusual approach, especially in todays web development world. But I've been developing stuff for over 20 years and in most cases I have to maintain my own code (my first PHP project was about 20 years ago). Without that somewhat unusual focus on stability I would spend my whole time updating existing code and couldn't get anything new done. And let's face it, in most situations you don't need the perfect tool, just something that gets the job done reliably (e.g. sending a query to a database and process the result). So I guess that is my usecase for PHP: A stable base for long-lasting and very low maintenance server-side code. The recent migration made me question that assumption, though. Is this still something that makes sense in your opinion or would you recommend to avoid using PHP for that? A project like PHP is the result of a lot of work from many different people and people, opinions and priorities change over time. The direction of PHP is determined by those who work on it and that's a good thing. I just want to avoid using the wrong tool for the job as this can quickly spiral into a lot of unnecessary complexity and (in a somewhat best case) end in a rewrite a few years later to stop the spiral. I routinely rely on PHP features that are not often talked about (read on sexy or fashionable) to greatly simplify my code: The alternate syntax for control structures as a lightweight template system, implicit type conversions, streams, SimpleXML, a DOM parser that can actually parse real-world HTML, PDOs and so on. PHP has a lot of small nuggets that make it a pretty useful toolbox if you don't overdo it. But did I overdo it? What I didn't realize before was the extend to which I relied on the stability of APIs and core extensions listed in the PHP manual. What will end up on the chopping block in the next few years? Can I rely on the alternate syntax for control structures? Will streams go since HTTP 2 and 3 made a mess of the whole HTTP protocol? I'm note sure how to evaluate the current situation. Hence the post. Migration details for those who're interested: I had PHP pegged as a dynamic language at it's core so I've used techniques like duck typing and dynamic properties here and there when they were the best compromise for simplicity and code locality.  This is nothing you would use in large or inexperienced teams but for a lot of small stuff this can keep code simple (it it doesn't amount to more than a few hundred lines). Sometimes I let projects grow organically like that over a few years until we consolidate parts that became to complex once the usecases became clear. Unfortunately this backfired on me during a recent migration. The amount of deprications and out right fatal errors caught me off guard. Dynamically extending objects got deprecated in PHP 8 except for stdClass and the AllowDynamicProperties attribute which sounds reasonable. Unfortunately I ran right into the corner case of attaching dynamic properties to a Generator which caused a fatal error. The rest of the code then used duck typing to work with those properties (basically just isset() checks that use the additional information if its available). In the end I found a solution using an anonymous class that implements the Iterator interface. But this is different between PHP 7 and 8 (because of the mixed type) so I had to implement my first version switch in PHP… which felt quite weird. I usually only have to do that in C to support corner cases for quirky compilers. So this spooked me quite a bit. Sorry for the long wall of text. Happy programming Stephan --- ## #119836 — Kamil Tekiela — 2023-04-08T20:28:29+00:00 URL: https://externals.io/message/119834#119836 · In reply to: #119834 Hi Stephan, Generally, PHP tries to keep as much backwards compatibility as possible. Breaking changes are limited to minimum and done in the least obstructive way possible. When a deprecation is introduced, you have at least 3 years to update your code. But PHP also tries to move forward and the language improves each year. We certainly got many more features than breaking changes. Just think of match expression, enums, attributes, constructor property promotion, new Random API, readonly properties/classes, first-class callable, consistent errors and many more. The biggest improvement in PHP 7 and 8 was a comprehensive type system. It's something that you don't have to use, therefore doesn't affect existing code much, but makes development so much more enjoyable and less bug-prone. I know I have discovered many bugs because of migration to PHP 8 and introduction of proper types. And this is the direction PHP is going in. The language is still dynamic and allows for taking the easy route, but new features focus on reducing bugs by making the code's behaviour less surprising. If you try to adhere to clean code principles, upgrades should not be a huge problem. Use static analysis and good tests. Learn and follow clean code practices, e.g. SOLID. Use abstraction in your code; it's better to change code only in one place than change it across hundreds of files. Some tools help you during migrations, such as Rector and phpcbf, but to use them proficiently, your code needs to be free from surprises. Dynamic properties are a very good example of surprising behaviour. By looking at the definition of the class, you don't know what properties it has. If any of the methods use undefined properties, both you and static analysers will be surprised by this. There are certain things you should avoid in your code like fire. Not because they might be removed from the language, but because they make your code unclean and cause bugs. Here is my list: - Arrays. Yes, they are a major feature of the language but also a major pain in the... Use proper data structures, which may use arrays internally, but don't use bare arrays in your code. Value objects and DTOs are invaluable. - Isset and empty. They are sometimes necessary and sometimes they are the easiest choice, but they hide so many bugs. Every time you use any of them, it should raise an immediate red flag. - References. I don't understand why the language still has this feature. Hack got rid of it and that was a very smart decision. You don't need references. Use them almost never. - Globals and superglobals. This should not need explaining. Pretty much in every language, these are pure evil. They make changes to the code an experience similar to disarming a bomb. It's tempting to use $_GET, $_POST, $_REQUEST anywhere in your code, but if you want to avoid bugs and surprises, you'd better stay away from it. There should probably be at most one place in every project where these are used. - `extract()` and `compact()`, and variable variables. These should only be used in a very tightly controlled scope, and even then, their usage can be contested. Ideally, variable variables should not exist in the language; we have arrays after all. - Sanitizing filters. Sanitization is too ambiguous term to be useful. What you should be using is validation and formatting. Validate your inputs to make sure they are the type/value you expect. Format the output so that it can't break the context it is in. - Loose comparison. I have liked that about PHP in the past, but in recent years I became a strong supporter of strict comparison. Why? Because "0" == false. Forbid using loose comparison in your coding standard and forget that it exists. Don't let the language make a fool out of you. You are the developer and you know what type you expect. Following these guidelines will not only help you avoid bugs in your code but also will make the upgrade process much less cumbersome. This and adhering to the strictest level of the static analysis tool of your choice is the recipe for success. Try to stay up to date with the changes. Every year when PHP releases a new version, go over the changelog and make an effort to learn and use new features. Even if your production is 3 years behind, you can try these out in your development environment. PHP will move forward and add new features, but sometimes it must also break some things to move forward. Kind Regards, Kamil Tekiela --- ## #119837 — Dan Liebner — 2023-04-08T20:47:01+00:00 URL: https://externals.io/message/119834#119837 · In reply to: #119836 I agree with the OP's sentiment here. If I was starting a codebase from scratch today, I'd probably go with Node. I find that writing modern JavaScript is way easier than writing PHP these days, and the breaking changes in newer PHP versions make writing code harder rather than easier. PHP is the foundation for many legacy codebases, and breaking old projects isn't really a great selling point of new PHP versions. Hopefully this scenario will affect enough people that 7.4 will continue to be maintained by some group of people into the foreseeable future. Best, Dan > Hi Stephan, > > Generally, PHP tries to keep as much backwards compatibility as possible. > Breaking changes are limited to minimum and done in the least obstructive > way possible. When a deprecation is introduced, you have at least 3 years > to update your code. > But PHP also tries to move forward and the language improves each year. We > certainly got many more features than breaking changes. Just think of match > expression, enums, attributes, constructor property promotion, new Random > API, readonly properties/classes, first-class callable, consistent errors > and many more. > The biggest improvement in PHP 7 and 8 was a comprehensive type system. > It's something that you don't have to use, therefore doesn't affect > existing code much, but makes development so much more enjoyable and less > bug-prone. I know I have discovered many bugs because of migration to PHP 8 > and introduction of proper types. > And this is the direction PHP is going in. The language is still dynamic > and allows for taking the easy route, but new features focus on reducing > bugs by making the code's behaviour less surprising. > > If you try to adhere to clean code principles, upgrades should not be a > huge problem. Use static analysis and good tests. Learn and follow clean > code practices, e.g. SOLID. Use abstraction in your code; it's better to > change code only in one place than change it across hundreds of files. Some > tools help you during migrations, such as Rector and phpcbf, but to use > them proficiently, your code needs to be free from surprises. Dynamic > properties are a very good example of surprising behaviour. By looking at > the definition of the class, you don't know what properties it has. If any > of the methods use undefined properties, both you and static analysers will > be surprised by this. > > There are certain things you should avoid in your code like fire. Not > because they might be removed from the language, but because they make your > code unclean and cause bugs. Here is my list: > - Arrays. Yes, they are a major feature of the language but also a major > pain in the... Use proper data structures, which may use arrays internally, > but don't use bare arrays in your code. Value objects and DTOs are > invaluable. > - Isset and empty. They are sometimes necessary and sometimes they are the > easiest choice, but they hide so many bugs. Every time you use any of them, > it should raise an immediate red flag. > - References. I don't understand why the language still has this feature. > Hack got rid of it and that was a very smart decision. You don't need > references. Use them almost never. > - Globals and superglobals. This should not need explaining. Pretty much in > every language, these are pure evil. They make changes to the code an > experience similar to disarming a bomb. It's tempting to use $_GET, $_POST, > $_REQUEST anywhere in your code, but if you want to avoid bugs and > surprises, you'd better stay away from it. There should probably be at most > one place in every project where these are used. > - `extract()` and `compact()`, and variable variables. These should only be > used in a very tightly controlled scope, and even then, their usage can be > contested. Ideally, variable variables should not exist in the language; we > have arrays after all. > - Sanitizing filters. Sanitization is too ambiguous term to be useful. What > you should be using is validation and formatting. Validate your inputs to > make sure they are the type/value you expect. Format the output so that it > can't break the context it is in. > - Loose comparison. I have liked that about PHP in the past, but in recent > years I became a strong supporter of strict comparison. Why? Because "0" == > false. Forbid using loose comparison in your coding standard and forget > that it exists. Don't let the language make a fool out of you. You are the > developer and you know what type you expect. > > Following these guidelines will not only help you avoid bugs in your code > but also will make the upgrade process much less cumbersome. This and > adhering to the strictest level of the static analysis tool of your choice > is the recipe for success. > > Try to stay up to date with the changes. Every year when PHP releases a new > version, go over the changelog and make an effort to learn and use new > features. Even if your production is 3 years behind, you can try these out > in your development environment. > > PHP will move forward and add new features, but sometimes it must also > break some things to move forward. > > Kind Regards, > Kamil Tekiela --- ## #119838 — Ilija Tovilo — 2023-04-08T21:04:39+00:00 URL: https://externals.io/message/119834#119838 · In reply to: #119834 Hi Stephan > 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. No worries, this seems like the appropriate place. > Is there a way to tell which APIs and language features will be stable > and which > might get changed or removed in the future? That way I could restrict > myself to > a stable subset for long-running projects (5 to 10 years). But I realize > that > such guarantees are difficult (or contra productive) when a language is > in flux > and I can understand if no one wants to do something like that. There's no such guarantee at the moment. Anything that is agreed upon by the 2/3 majority of voters is subject to change. > Some of my projects run for 5 to 10 years, in one case even 20 years. There are companies that offer extended lifecycle support for PHP versions that have officially reached EOL (examples being Zend or TuxCare). I'm not sure if those will get you to that 10 year mark. Note however that deprecation notices alone should not keep you from upgrading to a newer version, as they don't have any runtime effect with a correct production configuration and thus aren't considered breaking. We generally postpone larger breaking changes to major versions. In general, I do agree that we could minimize breaking changes more, and limit them to the things that actually provide a tangible benefit. Sadly, there's a conflict of interest here. There are people who want to keep running their existing websites without having to make any changes, and there are people who are using PHP daily and would like to see the language evolve. We would like to satisfy both of these groups but that is difficult when they are often directly opposed. I do think that if we only manage to satisfy the former, PHP will gradually become less and less significant. That would be sad. Ilija --- ## #119839 — Stephan Soller — 2023-04-08T22:48:18+00:00 URL: https://externals.io/message/119834#119839 · In reply to: #119838 > Hi Stephan > > > […] but I > > […] > > No worries, this seems like the appropriate place. > > > […] > > There's no such guarantee at the moment. Anything that is agreed upon > by the 2/3 majority of voters is subject to change. > > > […] > > There are companies that offer extended lifecycle support for PHP > versions that have officially reached EOL (examples being Zend or > TuxCare). I'm not sure if those will get you to that 10 year mark. > Note however that deprecation notices alone should not keep you from > upgrading to a newer version, as they don't have any runtime effect > with a correct production configuration and thus aren't considered > breaking. We generally postpone larger breaking changes to major > versions. In general, I do agree that we could minimize breaking > changes more, and limit them to the things that actually provide a > tangible benefit. Thanks for mentioning the extended lifecycle support. I wasn't aware of that. Looks like even some webhosters provide something similar so it might even be an option for small customers (restaurants, etc.). > > Sadly, there's a conflict of interest here. There are people who want > to keep running their existing websites without having to make any > changes, and there are people who are using PHP daily and would like > to see the language evolve. We would like to satisfy both of these > groups but that is difficult when they are often directly opposed. I > do think that if we only manage to satisfy the former, PHP will > gradually become less and less significant. That would be sad. Yes, this seems to be the prevalent mindset people like to group themselves into. I don't have any good answers about that but a few languages seemed to have handled that rather well. Fortran for one changed a lot since its inception while still being very stable. And before the first one says that it's dead, a dinosaur or whatever: I thought so as well before I worked at a super computing center for a while (around 2010). There pretty much everything was written in Fortran and still is as far as I can tell. The language gets an update every 10 years or so and it's still a pretty good tool for physicists and engineers to write high-performance simulations. With Fortran 95 you can almost write Ruby-like code if you care about readability. Not that physicist do that since they name everything alpha, theta, phidash, etc. which doesn't help. Anyway, there might be something interesting to learn from languages that navigated the same problems before. Disclaimer: I'm not that old but I'm curious how programming as a discipline is done and changes in different fields and industries. So I dabble in a lot of different things. Happy programming Stephan --- ## #119840 — Stephan Soller — 2023-04-09T01:09:29+00:00 URL: https://externals.io/message/119834#119840 · In reply to: #119837 It depends on your environment and usecase. For me Node is actually a curious case. Node itself and its APIs are very stable and the stability of each API is clearly marked in the docs. But the NPM based ecosystem is almost the exact opposite. Using it for anything else than quick experiments or throw-away prototypes is a maintenance nightmare for people like me. Maybe you can amortize that in larger companies with an operations department but from what I heard and observed over the years admins and programmers don't tend to talk much with each other and most programmers have no idea what it takes to keep their code running. And I can deeply emphasize with every admin who has to keep a node project with hundreds of dependencies running for more than a few months. Lets not even talk about security. Nodes core APIs are pretty network centric (that's where it came from) and it was a good fit for a HTTP based Matroska video streaming server project (among other things). But as it turns out JavaScript is a pretty bad language if you need bit manipulation with 64 bits. I'm still curious why they made BigInt signed one's-complement… Writing that stuff in C was a lot simpler. As for websites with node but without NPM... I did that a few times but for the last two years I tend to use Python aiohttp instead. They have well maintained Debian packages and builtin websocket support. And very complex client-server interactions are often the threshold where I switch from webservers like Apache or Nginx to an application server. As for using PHP for new code bases: I think a lot of programmers underestimate the flexibility and simplicity of file based webservers like Apache with PHP. If you keep it simple they allow projects to grow organically. Need a new backend for something? Just put a few lines of code into a new PHP file. No update to a centralized application server or routes required. Want to have a search-engine friendly dynamic website? Just write a basic HTML page with a few lines of PHP in it to insert the actual data (the alternate control structure syntax basically gives you a builtin template system). Want to generate static pages instead? Use output redirection. Want to add simple user authentication? Add a password protection in the webserver. Or tell it to get the user data from LDAP if you're in a company. It plays well with source control, there are a lot of dirt cheap webhosters for small customers, the list goes on and on. All of that makes PHP a pretty good tool that can solve a lot of problems in very simple ways. A lot of that are just small projects, small customers or the inglorious everyday work that nobody likes but someone has to do. So it doesn't get talked about much. Big companies and teams on the other hand spend a lot of time talking about what they do and then there are also consultants that preach whatever sells today. Most tend to talk about what everyone else is doing and this doesn't necessarily has anything to do with a simple solution for your specific problem at hand. Of course all of that can flip on a dime depending on your environment: Part of a team where everyone has decades of Java experience? You're not using PHP, or node for that matter. Doing a project with a lot of rookies that only know stuff like express and react? Guess what you'll be using. Part of a team where everyone has their dedicated non-overlapping area of responsibility and authority (content, design, programming, etc.)? Now there is potential to use the right tool for the job. And PHP can be just that in a lot of situations. Happy programming Stephan > I agree with the OP's sentiment here. If I was starting a codebase from > scratch today, I'd probably go with Node. I find that writing modern > JavaScript is way easier than writing PHP these days, and the breaking > changes in newer PHP versions make writing code harder rather than easier. > PHP is the foundation for many legacy codebases, and breaking old projects > isn't really a great selling point of new PHP versions. > > Hopefully this scenario will affect enough people that 7.4 will continue to > be maintained by some group of people into the foreseeable future. > > Best, > Dan > > > > > […] --- ## #119842 — Deleu — 2023-04-09T21:51:36+00:00 URL: https://externals.io/message/119834#119842 · In reply to: #119837 > I agree with the OP's sentiment here. If I was starting a codebase from > scratch today, I'd probably go with Node. I find that writing modern > JavaScript is way easier than writing PHP these days, and the breaking > changes in newer PHP versions make writing code harder rather than easier. > PHP is the foundation for many legacy codebases, and breaking old projects > isn't really a great selling point of new PHP versions. > > Hopefully this scenario will affect enough people that 7.4 will continue to > be maintained by some group of people into the foreseeable future. > > Best, > Dan > Can't disagree with this statement. I love PHP. I have been working with it for 13 years now. I can also make things work with PHP 8+ and I get what it brings. But the cost is catastrophic. If you have a legacy codebase hanging over your head you probably know how hard it is to upgrade it. If you have greenfield project with SA and 100% coverage, it's a peach. But what's the point of starting a greenfield project in PHP while Typescript is right there? The cost of PHP maintenance and it's bad reputation certainly makes it a language only for those that got hooked into it a decade ago and not something that makes sense to recommend for newcomers. With each deprecation, PHP pushes out more devs and companies into a different path. --- ## #119843 — Kamil Tekiela — 2023-04-09T22:10:38+00:00 URL: https://externals.io/message/119834#119843 · In reply to: #119842 > But what's the point of starting a greenfield project in PHP while Typescript is right there? If that is true then we have pushed PHP to its death. PHP is dead and we can move on to other projects. But that's obviously not true. I could claim the complete opposite: why start a project in Typescript when PHP is there and it's a more mature language? At the end of the day, it comes down to personal preference. The language is perfectly suitable for greenfield implementation. If it wasn't, then there would be RFCs trying to change things that are wrong with it. > But the cost is catastrophic. If you have a legacy codebase hanging over your head you probably know how hard it is to upgrade it. I wonder about this every time I hear this claim. What exactly changed in PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a little more difficult because of some of the recent deprecations, but that's still years ahead of us. So what's exactly driving people away from PHP 8? Why is the adoption dwindling? I'd rather say that the roadblocks people are facing in upgrading legacy projects are not specific to PHP 8, but rather a technical debt acquired over the past 10-15 years. Even if nothing would change in PHP 8, people would still complain about the upgrade because of unrelated reasons. But please prove me wrong. Is there actually any change in PHP 8.0 that is a major source of work? If PHP went in the wrong direction, let's suggest something to fix it. If there are no suggestions for improvement then what are people complaining about? Regards, Kamil --- ## #119844 — Deleu — 2023-04-09T23:44:24+00:00 URL: https://externals.io/message/119834#119844 · In reply to: #119843 > > […] > your head you probably know how hard it is to upgrade it. > > I wonder about this every time I hear this claim. What exactly changed in > PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may > be a little more difficult because of some of the recent deprecations, but > that's still years ahead of us. So what's exactly driving people away from > PHP 8? Why is the adoption dwindling? > > I'd rather say that the roadblocks people are facing in upgrading legacy > projects are not specific to PHP 8, but rather a technical debt acquired > over the past 10-15 years. Even if nothing would change in PHP 8, people > would still complain about the upgrade because of unrelated reasons. But > please prove me wrong. Is there actually any change in PHP 8.0 that is a > major source of work? > > If PHP went in the wrong direction, let's suggest something to fix it. If > there are no suggestions for improvement then what are people complaining > about? > > > Regards, > Kamil > Here are the top-of-my-head most relevant stuff I've read over the years on the matter. https://yoast.com/developer-blog/the-2020-wordpress-and-php-8-compatibility-report/ https://markbakeruk.net/2022/05/22/php-8-2-the-release-of-deprecations/ https://24daysindecember.net/2022/12/06/evolving-php/ https://24daysindecember.net/2022/12/19/maintenance-art/ https://mobile.twitter.com/jrf_nl/status/1459221549429542920 https://24daysindecember.net/2020/12/21/a-perfect-storm/ https://mobile.twitter.com/jrf_nl/status/1558589727766417411 Unfortunately I couldn't find where, but I remember reading that PHP 7.2 deprecation of non-countable types was one of the biggest "busywork" generator of the PHP 7 series. It made an extremely large impact at public and private projects across the world for something with questionable benefits. https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types Over the course of PHP 7 and 8, there were significant concerns on how problematic PHP deprecations and breaking changes were. Now we're starting to see the result of such concerns being ignored. This isn't the first time someone mentions on PHP internals that it's getting harder and harder to stay with PHP, but it's never really received with an open mind. It's either "you don't have to run deprecation-free code" or "you've had years to get rid of that deprecation error, tough luck if you didn't". I love PHP and I built my career around it. I have zero interest in starting from scratch in another language, but I've lost count on how many projects, friends and companies around me have already made the switch to Typescript. It's getting harder and harder to argue in favour of staying with PHP. -- Marco Deleu --- ## #119845 — Deleu — 2023-04-10T03:17:21+00:00 URL: https://externals.io/message/119834#119845 · In reply to: #119843 > > I'd rather say that the roadblocks people are facing in upgrading legacy > projects are not specific to PHP 8, but rather a technical debt acquired > over the past 10-15 years. Even if nothing would change in PHP 8, people > would still complain about the upgrade because of unrelated reasons. > > > Regards, > Kamil > I'm sorry for the double-answer but this snippet striked me a lot. I'm quite curious to read a follow up on what you mean by unrelated reasons here. Suppose a parallel universe that code written in PHP 5.6 runs without any changes in PHP 8.2. What unrelated changes would people have to not upgrade? If the code runs exactly the same, there's no warnings converted into exceptions that change code execution, no deprecations, no behavior changes, what is it that people would complain about? Or maybe when you wrote "Even if nothing would change in PHP 8" you meant something different than what I interpreted? --- ## #119846 — Deleu — 2023-04-10T03:32:59+00:00 URL: https://externals.io/message/119834#119846 · In reply to: #119838 > > Sadly, there's a conflict of interest here. There are people who want > to keep running their existing websites without having to make any > changes, and there are people who are using PHP daily and would like > to see the language evolve. We would like to satisfy both of these > groups but that is difficult when they are often directly opposed. I > do think that if we only manage to satisfy the former, PHP will > gradually become less and less significant. That would be sad. > > Ilija That makes total sense to me. On the other hand, throwing the existing community out and chasing after a new community puts PHP at a very delicate spot. There's a large world out there that thinks PHP is still PHP 4. Of the large group of PHP adopters that stayed with the language for the last decade, a large set seem to have their interests neglected and are being forced into greenfield/rewrite. If you've bet money on PHP 15 years ago and you're now being forced by the language to stay behind or rewrite, what are the odds that PHP will keep being the betting choice? --- ## #119847 — Robert Landers — 2023-04-10T08:30:15+00:00 URL: https://externals.io/message/119834#119847 · In reply to: #119846 Here are my 2 cents: The "dangerous" part of PHP upgrades is when you have more than one server and since you can't migrate a distributed system atomically, it often means that for a period of time, your code needs to support multiple versions (and you probably *always* have to do this for libraries). Personally, I've been bitten by small, undocumented, BC breaks that get marked 'wontfix' once reported, because fixing it after a release is considered a BC break. All I can do is facepalm while I update the code to handle different versions of PHP. I freakin love PHP, so I'm not going anywhere, but it would be amazing if core devs contributed to Rector (or something like it) that allowed you to run a simple tool to upgrade your code from "8.2 compatible" code to "8.2 + 8.3 compatible code" and then to "8.3-only compatible" code. The community does its best, but the core devs working on it know about the undocumented bits and probably the most efficient implementation. For all I know, you all are already doing this, and if so, you should tell the world. Cheers, Rob --- ## #119848 — Andreas Leathley — 2023-04-10T08:48:03+00:00 URL: https://externals.io/message/119834#119848 · In reply to: #119844 > Over the course of PHP 7 and 8, there were significant concerns on how > problematic PHP deprecations and breaking changes were. Now we're starting > to see the result of such concerns being ignored. This isn't the first time > someone mentions on PHP internals that it's getting harder and harder to > stay with PHP, but it's never really received with an open mind. It's > either "you don't have to run deprecation-free code" or "you've had years > to get rid of that deprecation error, tough luck if you didn't". > > I love PHP and I built my career around it. I have zero interest in > starting from scratch in another language, but I've lost count on how many > projects, friends and companies around me have already made the switch to > Typescript. It's getting harder and harder to argue in favour of staying > with PHP. The PHP ecosystem even just in the last 10 years has changed completely, with composer, more mature frameworks, easily usable independent components and even static analyzers. For me that ecosystem is the big value proposition of PHP, in addition to a good standard library. Typescript has a completely different value proposition, and the language itself is usually not the deciding factor, as there is so much more to it. Only through the deprecations and the type system does PHP even offer some similar features as Typescript - like type checks and the possibility of a static analyzer. If all these changes would not have happened, people likely would argue even more that they had to switch to Typescript, because of the missing type safety in PHP. Nowadays there are even tools now like Rector that can help you automatically upgrade your codebase - that is also a new value proposition. My projects were affected by all the new warnings, deprecations etc. over the years, but I found countless bugs because of those (and many bad choices - is count($string) really what I wanted?). The language warning you when you are likely doing something with little sense is a huge value proposition - otherwise why are people using Typescript instead of Javascript? It would be interesting to know why some people are having such huge problems upgrading their applications, as I think those would often be good stories with something to learn in them. So to the original poster or other people with big problems when upgrading, writing a blog article detailing what happened would be helpful to evaluate if the PHP project could improve something, or even why something broke. And just as a sidenote: I never have more things breaking than when trying to upgrade a JS/TS-project, because of changes in NodeJS, because of slight breaks in dependencies, etc. To me that clearly works better in PHP, but experiences can differ. --- ## #119849 — Kamil Tekiela — 2023-04-10T09:53:13+00:00 URL: https://externals.io/message/119834#119849 · In reply to: #119845 > > Or maybe when you wrote "Even if nothing would change in PHP 8" you meant > something different than what I interpreted? > I meant things like refactoring, fixing bugs, updating dependencies. Changes in code unrelated to changes in the language. When people leave technical debt for later, the upgrade becomes more painful to them. --- ## #119850 — Lynn — 2023-04-10T10:00:24+00:00 URL: https://externals.io/message/119834#119850 · In reply to: #119844 > > Unfortunately I couldn't find where, but I remember reading that PHP 7.2 > deprecation of non-countable types was one of the biggest "busywork" > generator of the PHP 7 series. It made an extremely large impact at public > and private projects across the world for something with questionable > benefits. > > https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types I'm very thankful for fixes like this, it made us discover a lot of bugs in a 20 year old product that we are still actively developing on. --- ## #119852 — Jeffrey Dafoe — 2023-04-10T12:35:44+00:00 URL: https://externals.io/message/119834#119852 · In reply to: #119843 > I wonder about this every time I hear this claim. What exactly changed in PHP > 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a > little more difficult because of some of the recent deprecations, but that's > still years ahead of us. So what's exactly driving people away from PHP 8? > Why is the adoption dwindling? The change in null handling. We have a codebase that dates to 1998. It's fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that took almost a year due to the change in null handling. We have 40 XML and JSON APIs with various banks. Elements may or may not exist. The database, which is 45TB, has nulls all over it. And when it was all "upgraded" to run on PHP8 all we really got that was useful to us is two new string functions. And a codebase that now has ?? as every third line. -Jeff --- ## #119855 — Craig Francis — 2023-04-10T12:58:58+00:00 URL: https://externals.io/message/119834#119855 · In reply to: #119843 > I wonder about this every time I hear this claim. What exactly changed in PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a little more difficult because of some of the recent deprecations, but that's still years ahead of us. Most of the deprecations and changes do make sense, and while deprecating dynamic properties is going to be a pain, I think it's going to be worth it (like undefined variables), same with ${} string interpolation (better to be consistent); and I know it's been mentioned in this thread, but `utf8_decode` does get misused a lot (read the RFC as to why). But I do not understand "Passing null to parameter # of type string is deprecated" specifically. I should note that the other coercion/type tweaks that G.B.P (Girgias) is suggesting, and has partially implemented, do make sense: https://github.com/Girgias/unify-typing-modes-rfc And (fortunately) `NULL` coercion still works when concatenating `NULL` to a string, adding `NULL` to an integer, `NULL` being treated as false, etc. One team of developers I know are still finding these issues well over a year later (they also introduce new code that trips it as well); two other teams specifically ignore this deprecation (far too many instances to "fix"), and one team is still to decide what they are going to do (annoyingly they are still using 7.4). Even Rector gives up and uses `(string) $var` for every variable that's a non-nullable string, which can result in thousands of changes in a project (that's for the ~434 function arguments being checked; personally I'd have only gone with 335 of the ~997): https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't using strict types, that's going to cause lots of random and unexpected problems. Craig PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it would have been voted down, and then used to justify the type error): https://wiki.php.net/rfc/null_coercion_consistency --- ## #119859 — Thomas Bley — 2023-04-10T14:37:53+00:00 URL: https://externals.io/message/119834#119859 · In reply to: #119855 Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g. https://3v4l.org/VfAr4 has 4 different outputs between php 7.x and 8.x. From userland perspective, having Craig Francis hat am 10.04.2023 14:58 CEST geschrieben: > > > > > […] > > > > Most of the deprecations and changes do make sense, and while deprecating dynamic properties is going to be a pain, I think it's going to be worth it (like undefined variables), same with ${} string interpolation (better to be consistent); and I know it's been mentioned in this thread, but `utf8_decode` does get misused a lot (read the RFC as to why). > > But I do not understand "Passing null to parameter # of type string is deprecated" specifically. > > I should note that the other coercion/type tweaks that G.B.P (Girgias) is suggesting, and has partially implemented, do make sense: > > https://github.com/Girgias/unify-typing-modes-rfc > > And (fortunately) `NULL` coercion still works when concatenating `NULL` to a string, adding `NULL` to an integer, `NULL` being treated as false, etc. > > One team of developers I know are still finding these issues well over a year later (they also introduce new code that trips it as well); two other teams specifically ignore this deprecation (far too many instances to "fix"), and one team is still to decide what they are going to do (annoyingly they are still using 7.4). > > Even Rector gives up and uses `(string) $var` for every variable that's a non-nullable string, which can result in thousands of changes in a project (that's for the ~434 function arguments being checked; personally I'd have only gone with 335 of the ~997): > > https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php > > Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't using strict types, that's going to cause lots of random and unexpected problems. > > Craig > > > > PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it would have been voted down, and then used to justify the type error): > > https://wiki.php.net/rfc/null_coercion_consistency --- ## #119860 — tim@bastelstu.be — 2023-04-10T14:48:41+00:00 URL: https://externals.io/message/119834#119860 · In reply to: #119859 Hi > Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g. > > https://3v4l.org/VfAr4 > > has 4 different outputs between php 7.x and 8.x. From userland perspective, having Tim Düsterhus hat am 10.04.2023 16:48 CEST geschrieben: > > > Hi > > > > […] > > No, it has two different outputs, one for PHP 7, one for PHP 8. > > It also has two different deprecation notices, one concerning the > behavioral change between PHP 7 and PHP 8 we're seeing and one > concerning an upcoming behavioral change with PHP 9. > > However in all PHP versions the function call clearly is non-sense, > because 'null' clearly cannot be a substring of a string, as it is a > completely unrelated data type. > > Best regards > Tim Düsterhus > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #119862 — Mark Baker — 2023-04-10T15:34:42+00:00 URL: https://externals.io/message/119834#119862 · In reply to: #119848 > It would be interesting to know why some people are having such huge > problems upgrading their applications, as I think those would often be > good stories with something to learn in them. So to the original poster > or other people with big problems when upgrading, writing a blog article > detailing what happened would be helpful to evaluate if the PHP project > could improve something, or even why something broke. Would it really be considered helpful? When I or others like jrf who see the potential problems try to warn about these issues here on Internals, our concerns are generally ignored, or it's considered that we don't want to allow PHP to move forward, or that we're simply scaremongering. We aren't against PHP moving forward; we're not advocating that changes and improvements shouldn't be made. We are saying that they shouldn't be purely technical discussions about implementation here on Internals, but there should also be consideration for the impact on existing userland code. All too many of the changes made in 8.0, 8.1 and 8.2 had no impact assessment, no consideration of how much effort might be required for users to make the necessary changes in their code. Thankfully, I've started seeing some effort again to include a risk analysis or impact assessment in some of the more recent RFCs. And many of those RFCs work on the assumption that all existing PHP codebases are adequately covered by unit tests to identify the points where changes need to be made, and written well enough that any designated fix will always work. But in the real world, that is rarely the case, particularly with older codebases. Too often the RFCs seems to assume the happy path; with testing for edge cases in developers applications after release. > Nowadays there are even tools now like Rector that can help you automatically > upgrade your codebase - that is also a new value proposition. Tools like rector can help, particularly for developers that are specifically upgrading from one PHP version to another; and rector is certainly a game-changer there in the same way that Composer changed the way that we build applications and manage dependencies. Where rector is less useful is if we need to maintain the same codebase across multiple PHP versions, which is the case for many libraries, as well as some of the tools that we use for developing and testing. -- Mark Baker --- ## #119864 — Alex Wells — 2023-04-10T16:02:24+00:00 URL: https://externals.io/message/119834#119864 · In reply to: #119855 On Mon, Apr 10, 2023 at 3:59 PM Craig Francis wrote: > One team of developers I know are still finding these issues well over a > year later (they also introduce new code that trips it as well); two other > teams specifically ignore this deprecation (far too many instances to > "fix"), and one team is still to decide what they are going to do > (annoyingly they are still using 7.4). How can they be finding those issues over a year later? Do they have pieces of completely untested code that has never been called in more than a year? If so, they have bigger problems than PHP deprecations. Otherwise, they should see the deprecation logs either on production or on CI. I highly doubt they're not collecting any logs from production, so they had more than a year to collect all the places where a deprecation is triggered and fix them. Speaking of those that ignore them, well, I'm not sure what the expectation is. Do they think the deprecation will simply go away on itself? Or do they expect the already small PHP team to infinitely support their code, sacrificing other developers' experience? Also, can you name an actively developed software product that introduced no breaking changes in the span of the expected 10 years? Besides, as mentioned before, it's likely that such projects are also using at least some other 3rd party PHP dependencies, and those usually have a shorter BC lifespan than PHP and require more efforts to keep them up-to-date. Again, is the expectation here to infinitely keep the backwards-compatibility? If so, why is it that almost every dependency follows Semver specifically to manage breaking changes, and there are practically no examples of actually avoiding breaking changes in the long term? --- ## #119865 — Pierre Joye — 2023-04-10T16:17:36+00:00 URL: https://externals.io/message/119834#119865 · In reply to: #119834 hello, On Sun, Apr 9, 2023, 1:37 AM Stephan Soller 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 --- ## #119866 — Dan Liebner — 2023-04-10T16:45:13+00:00 URL: https://externals.io/message/119834#119866 · In reply to: #119852 > > The change in null handling. We have a codebase that dates to 1998. It's > fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that > took almost a year due to the change in null handling. We have 40 XML and > JSON APIs with various banks. Elements may or may not exist. The database, > which is 45TB, has nulls all over it. And when it was all "upgraded" to run > on PHP8 all we really got that was useful to us is two new string > functions. And a codebase that now has ?? as every third line. This is probably my biggest stylistic gripe with PHP 8+ just because of how ubiquitous the "undefined array index" scenario is. In JavaScript: ``` let obj = {}; obj['undefinedkey'] === undefined; let str = `Welcome, ${obj['undefinedkey'] ?? 'Customer'}!`; if( obj['undefinedkey'] || $obj['undefinedkey2'] ) doSomething(); ``` In PHP: ``` $obj = []; ($obj['undefinedkey'] ?? null) === null; $str = "Welcome, " . ($obj['undefinedkey'] ?? 'Customer') . "!"; if( ( $obj['undefinedkey'] ?? null) || ($obj['undefinedkey2'] ?? null) ) doSomething(); ``` > > > […] > in PHP > > […] > a > > […] > that's > > […] > 8? > > […] > > The change in null handling. We have a codebase that dates to 1998. It's > fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that > took almost a year due to the change in null handling. We have 40 XML and > JSON APIs with various banks. Elements may or may not exist. The database, > which is 45TB, has nulls all over it. And when it was all "upgraded" to run > on PHP8 all we really got that was useful to us is two new string > functions. And a codebase that now has ?? as every third line. > > -Jeff > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #119867 — Arvids Godjuks — 2023-04-10T17:04:26+00:00 URL: https://externals.io/message/119834#119867 · In reply to: #119865 > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > wrote: > > > […] > I > > […] > > > 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 > Hello! I also want to add that PHP is purely developed by open-source contributor efforts who are limited in their numbers and not a lot of them are getting compensated for it (exceptions being specific people working for companies who have a vested interest in PHP development like JetBrains, hosting giants and some others. And now PHP Foundation is there to help people get paid for their crucial roles in PHP project and their dedicated time). You also have a world on your hands that is changing - everywhere you look things are going for a more typed approach. That's what developers of today expect. That's the reality of how modern libraries are developed and old libraries have been actively migrating to strict type code bases. This code quality improvement absolutely takes a huge load off those developers' shoulders. I'm seeing libraries out there now that basically require PHP 8.1 as a minimum because Enums are all the rage and almost half the libraries I use have introduced them in their code in the latest versions and authors just flat-out tell you "use the older version of the lib or update your project" (and I have at least 7 of them in my code already and that project will never run on anything lower than 8.2). Some of the biggest libraries out there have fully adopted SemVer and will bump the minimal PHP version quite aggressively. And will tell you to pay for commercial support or deal with it on your own. And now the Union types are coming and I expect that to get adopted at a rapid pace by everyone and their dog. Just as owning your own house means you need to do the upkeep on a yearly basis or it will become a mess, the same is with code and not maintaining it - eventually, the roof will cave in and the costs of fixing it all will skyrocket. And, frankly, this is the feeling I get from a lot of this thread - the roof has collapsed and people are put into impossible positions of "no, you can't have the time or resources to update the project to the new PHP version, here are 20 KPI's for the next 3 months you need to hit". The codebase was run on a credit of "this will be fixed down the line". Well, the debt collectors now what their debt, their late fees and lawyers want their slice of the pie. Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Telegram: @psihius https://t.me/psihius --- Next page: https://externals.io/message/119834.md?page=2