> > That's 1.5 million hours, which is 171 developer-years. > > If we're going to imagine numbers; there are 6 million PHP developers > in the world*. If on average they each lose just 1 hour per year by > making typos and accidentally creating a properties dynamically, > that's 6 million hours, or 684.93 years! > > So the value delivered by this change would be 4 times the cost just > in the first year. And then every year after that it's pure benefit.
And as many of those who wish to, can opt-in to the attribute/feature can save themselves that time (and probably should!). We probably will for our code, tbh! But forcing this issue is going to be massively destructive to the ecosystem. Not everything is brand-spanking new. Some things just work well and don't get updated that often. > > What I'm scared about is about our 42 dependencies in composer.json, > > How about sponsoring each of your dependencies some money, to > encourage them to check if their code is compatible after this change, > and fix it if it isn't. You are trying to solve a technological problem with an economic solution. And one that requires that the entire ocean be boiled before it is solved. We already do give money to several places, and would like to give more. And we will. But that's not going to fix this, unless everyone does. And not everyone will. We happen to make money; not a lot of other projects do. We ourselves are open source. We don't get more than a handful of donations per year. This doesn't seem to be the right way to solve this problem. > If a dependency is used by even just 1000 companies, and each of those > companies chips in $50, then $50,000 will fund many months of work on > that dependency. > > Most open source is done by people in their free time. Because > companies keep refusing to fund open source. > > > might be stuck on a framework or something that's no longer being updated, > > Having companies sponsor open source projects makes it less likely > they will be abandoned. Maybe, but not always. Sometimes people just lose interest. But again, you're proposing to potentially break a big chunk of packages in hopes that an economic model that has not successfully worked anywhere else is going to work here. That seems cavalier. Right now, to get a collection of packages that work between php 7.4 and 8.0, we've had to spend tremendous amounts of work just to get there - and we had to pull 7.3 support in the process. I didn't want to do that; I want our software to be available to as many people as possible - not everyone has the freedom to install their own version of PHP - some are on crappy shared hosting or have to deal with some creaky IT department. Every single backwards-incompatible change shrinks our version-sandwich down further, especially in the context of packages. Again, I can add the new attributes to our own software today, and that means we're OK - but I can't speak to every single package we're dependent on or *they* are dependent on. -B. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
