Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116331
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34
Mime-Version: 1.0
Message-ID: <e707e99c-6fe8-4a14-89f5-2e11b2de1fd4@www.fastmail.com>
In-Reply-To: 
 <CAF+90c9GWiMYBjBZUAD72z8JXLBVKyHwAkY=jrorszUyq+M2Ow@mail.gmail.com>
References: 
 <CAF+90c_wDsjuMFAoQLehkn5GeoLv5GByczF+o-eDmYe+VVRxTA@mail.gmail.com>
 <DC6B97F4-C8F4-463D-9F33-74227AE5EC74@php.net>
 <0A40B090-43E3-484F-B67F-175C3B8F7CD6@php.net>
 <CAF+90c-igAJ0ZFbvbuKtZyxN99y-kDr_VVm9FDcGorLcb3xWyQ@mail.gmail.com>
 <CAF+90c9GWiMYBjBZUAD72z8JXLBVKyHwAkY=jrorszUyq+M2Ow@mail.gmail.com>
Date: Fri, 12 Nov 2021 11:43:49 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Nov 12, 2021, at 10:56 AM, Nikita Popov wrote:
> On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov <nikita.ppv@gmail.com> wr=
ote:
>
>> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey <ramsey@php.net> wrote:
>>
>>> > On Nov 12, 2021, at 10:10, Derick Rethans <derick@php.net> wrote:
>>> >
>>> > On 12 November 2021 13:07:42 GMT, Nikita Popov <nikita.ppv@gmail.c=
om>
>>> 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 befor=
e we
>>> deprecate it.
>>> >
>>> > cheers
>>> > Derick
>>>
>>>
>>> I=E2=80=99ve voted no for the same reason.
>>>
>>> I like this change, but the deprecation in 8.2 seems too disruptive.=
 I=E2=80=99d
>>> rather promote our intent to deprecate this with a statement in the
>>> manual that says something like, =E2=80=9CThis feature will be depre=
cated in
>>> PHP 8.3 and removed in 9.0.=E2=80=9D
>>
>>
>> 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 i=
ssue
>> 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, bu=
t if
>> the choice existed I'd always go for deprecating early in the major r=
elease
>> cycle, rather than late.
>>
>
> Another thing I want to add here is that in this instance, I think tha=
t 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 co=
urse,
> 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 proper=
ties
> 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 runni=
ng with deprecations on in production is doing it wrong and will get bit=
ten 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 the=
m, that's... a different problem that cannot be solved by not issuing de=
precations.

--Larry Garfield