On Tuesday, 23 January 2024 at 16:37, Larry Garfield <la...@garfieldtech.com> wrote:
> On Tue, Jan 23, 2024, at 2:18 AM, Gina P. Banyard wrote: > > > I fundamentally disagree with the logic that we somehow need to "plan" > > deprecations around how much time we need to provide users to upgrade. > > > I categorically disagree here. PHP has a terrible reputation, even among its > own boosters, for breaking people's stuff and making upgrades harder. That is > partially deserved, partially not. (I've written in defense of Internals' > improvements extensively.) But as a project we need to consider both the > practical and social impact of any breaking changes. PHP has a terrible reputation because it didn't try to fix any of its crap for years. PHP has a terrible reputation because it added random ill designed stuff at random prior to the RFC process. PHP has a terrible reputation because it has insane bonkers semantics. PHP has a terrible reputation because its image is stuck in 2005. PHP has a terrible reputation because of projects written in PHP having "bad" codebases. etc. etc. I've stopped counting how many times I've been sent "PHP: a fractal of bad design" [1], how many times have people have brought up to me the fact PHP is the only language they know that undeprecated something (for reference is_a() in 5.1), and other countless stuff that I need to hear semi often. Internals is blamed for making upgrades hard, the life of library maintainers hell, and everything that could be assigned blame to internals. But I have never seen internals tell userland to promote deprecations to exceptions, userland came up with this, and uses this as a tool to harass library maintainers. Maybe I'm just weird, but I don't actually care that projects still use PHP 7, 5, 4, or 3. Because there will always be such projects, and basing my decisions on those makes no sense to me. It helps that I also hear people that are satisfied and happy with the language being tighter, but those are rarely said publicly, because there is no need to complain online when one has nothing to complain about. And again, I frankly don't believe that providing 2, 3, 5, 10 years of deprecation before a removal is effectively different from providing 1 year. People will either fix it immediately, or leave it until the end of time and still make a fuss about it. > > You assert that this is 1-2 orders of magnitude less impactful than undefined > vars or null string params were. I have no data on that off hand either way, > so cannot confirm or deny that estimate. (If you do, that would be very > helpful. No sarcasm, it really would.) It is definitely more > tooling-handleable, and it sounds like there's ample existing tooling for it, > so that's great and will help, but as we've noted many times, people using > good tooling are the minority. I don't need data to know this change is less impactful. Undefined vars requires either tracking the source of the first usage, or guarding every usage with a null coalesce operator. Implicit coercions require the same thing, either tracking the source, guarding every usage, or doing the worst option to just chug an explicit cast in front. And both of these things can happen countless times all over the code base, thus flooding logs. Compared to this change, which requires changing the unique definition of the offending function/method signature. I cannot comprehend how at the same time we need to treat users as capable, intelligent, knowledge people when introducing features. And at the same time consider them to be incompetent, and lacking skills to use tooling. For this deprecation the tooling _already_ exists, if people don't want to use it, why? If people don't know about it, why? If people don't trust it, why? This is different from a bunch of other changes where any tooling would be brand new. > > There is indeed a related discussion around scheduling, deprecation timelines > in general, etc. As I said, I've tried to start that discussion in the past > and was mostly ignored. > > Maybe "all deprecations last for X releases, whatever the number" is a good > policy to have; I don't know. Deciding now that there will be an 8.5 and then > a 9.0 is also a viable option, which will also give 2 years grace period for > users to get up to speed on this change. That's the entire point of > deprecations. Maybe because fixed major release cycles for a programming language is just a bad idea? Because what does a "major" release entail for a programming language? And if someone wants to deprecate something in 8.5 what do we tell them? No? PHP is an open source project, people come and go, and start contributing at different times. And telling someone nah sorry you should have started contributing 3 years ago to be able to make this change is extremely toxic IMHO? (c.f. the debacle from last year) And when thinking of those sorts of policies, the health of the project and its contributors must be front and centre. If there is no one to maintain, or that wants to maintain PHP, it doesn't matter that there are downstream users or not. Yes, PHP has the Foundation now, and yes they pay me and others to work on PHP, but I don't think its mere existence means that the project is still not at risk. And anything that leads to friction for new people to contribute, or existing contributors to burn out, is just bad. One should be able to improve PHP the moment one starts contributing, regardless of the nature of said improvement. > > What I do not think is a good approach is "meh, we'll deprecate whenever, and > remove whenever, we'll tell you when we get there." That's not helpful to our > downstream users, without whom there is no project. PHP is at a scale where > we have to think about such things. Because every time we give someone a > months long upgrade process, users migrate to Go, Node, etc. Implying something could be removed whenever really feels like you are saying we could just remove stuff in 8.4. Not having a date for PHP 9 is not equivalent to something being removed whenever. Again, maybe I am just weird, but if the code is in such a state that people rewrite their code, regardless of in another language or not, I see this as a win. People already migrate to other languages because they don't think PHP is good enough. Also, am I the only one remembering people wanting a PHP 7.5 with no features and just deprecations or what? This clearly gave me the impression people wanted to get rid of problematic baggage, instead of what has been recently portrayed. Probably, because for once, it was the other crowd shouting into internals? Best regards, Gina P. Banyard [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
