On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield <la...@garfieldtech.com> wrote:
> 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 > > I don't think this should be deprecated or removed at all. However, I agree that if it is going to be removed, the more time/versions that exists between deprecation and removal, the better. -- Chase Peeler chasepee...@gmail.com
