Hi Brady, 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.
PHP has had many breaking changes over the years. PHP 8.1 introduced a much more annoying deprecation: Deprecate passing null to non-nullable arguments of internal functions. This one I would have no trouble believing that it impacts 50% or even the majority of PHP projects. Dynamic properties compared to this should be a piece of cake. 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. Regards, Kamil
