> This is a little bit overly dramatic. This isn't such a huge change that > would affect 50% of existing projects. It's likely to affect a small number > of projects in a very limited way. > It's also not true that developers will slap #[AllowDynamicProperties] on > every class. That would imply that every class in their project is using > dynamic properties. That would be absurd. If it's truly the case that every > class in 50% of the projects uses dynamic properties then we should not > consider this RFC at all. The whole premise of it is that it's highly > unlikely that many people are using dynamic properties on purpose. It's true > that many old unmaintained projects might use it as a feature, but the > keyword is "unmaintained". I would not trust dependencies that haven't been > kept up to date for a few years. > > I doubt that having to add a single attribute to a selected few classes would > be such a major issue that projects would decide to stay on PHP 8.1 rather > than upgrade. It's not comparable to Python 2/3 situation IMHO. > > I would be interested to know some numbers from Snipe-IT. Have you done a > preliminary analysis of your codebase of how many classes are actually using > dynamic properties? From a brief look, I can see that usually most properties > are declared.
Sorry, I didn't mean to sound dramatic, just trying to share my concerns. I suspect that you're very right, and *very very few* projects use dynamic properties on purpose (in our own code, we probably don't ever _mean_ to, except maybe for our Custom Fields feature, but we could do the attribute for that one or so class(es)), but that's not my point. I suspect many of our _dependencies_ might be using it (by accident, to your point!). But I can't control every package in my composer.json, which is where I'm worried. I can't force those developers to do what I want, and I don't want to be stuck in a 'version sandwich' because I'm waiting for one of them to change something. And maybe when they *do* try and change something, they might also change the interface (a violation of semver, but, it happens in the wild, more often than we would like). We have to support old and new versions of php and that can make our Composer situation a real nightmare (I just dragged us forward to be able to work in PHPv8, and it was far harder than it needed to be). I'm not worried about our code at **all** - we write it! We can change it (and we'd be good citizens, I promise, we would!) And that attribute is ignored on versions of PHP that don't support it; which'd be fine for us. That's a fair ask, and we'd do it. What I'm scared about is about our 42 dependencies in composer.json, and the ~400k bytes of dependencies described by our composer.lock. And I'm worried about other projects that have even more dependencies, or might be stuck on a framework or something that's no longer being updated, but they can't migrate off of for whatever reason. I wouldn't wish that on anyone. Thank you for considering, and for your extremely well-written response, -B. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
