On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey <ram...@php.net> wrote: > >> > On Nov 12, 2021, at 10:10, Derick Rethans <der...@php.net> wrote: >> > >> > On 12 November 2021 13:07:42 GMT, Nikita Popov <nikita....@gmail.com> >> wrote: >> >> Hi internals, >> >> >> >> I've opened the vote on >> >> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will >> close >> >> 2021-11-26. >> > >> > I've voted no on this one. Not because I don't like the idea, but >> because I think the timeline for deprecation and removal is way too fast. >> > >> > This is IMO not something important enough to cause a fairly large BC >> break for, and it should wait until the last in the 8.x series before we >> deprecate it. >> > >> > cheers >> > Derick >> >> >> I’ve voted no for the same reason. >> >> I like this change, but the deprecation in 8.2 seems too disruptive. I’d >> rather promote our intent to deprecate this with a statement in the >> manual that says something like, “This feature will be deprecated in >> PHP 8.3 and removed in 9.0.” > > > FWIW I think we should always deprecate things as soon as possible, to > give people the maximum amount of awareness and time to address the issue > before the actual removal occurs. Most people will not be aware they need > to take action if it's just a note in the manual. For that reason, I find > it generally preferable to deprecate something closer to PHP 8.0 than to > 8.4, which would be directly before a major version with limited time to > act. Now, we don't usually tend to optimize for "time of deprecation" > because that requires planning deprecations many years in advance, but if > the choice existed I'd always go for deprecating early in the major release > cycle, rather than late. > Another thing I want to add here is that in this instance, I think that the deprecation warning is really helpful for updating your code. It tells you exactly which property on which class is being created dynamically, so you can quickly go through these and add missing property declarations or #[AllowDynamicProperties] attributes. Without the deprecation warning in place, you need a static analyzer to find problematic cases. And of course, that only works well if you already have a fully typed code base that is reasonably clean under static analysis. At the same time, this change is most likely to affect projects where this is not the case. If you are already using a static analyzer, you probably don't use dynamic properties anyway, as these things tend to be incompatible. Regards, Nikita
