On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote: > 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
Also a reminder that deprecations are not errors; PHPUnit very recently changed to not complain about deprecations by default. And anyone running with deprecations on in production is doing it wrong and will get bitten whenever the deprecation is enabled. I have to agree with Nikita here. Give people as much deprecation time as possible; if people are misunderstanding deprecations and abusing them, that's... a different problem that cannot be solved by not issuing deprecations. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
