Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116330
MIME-Version: 1.0
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>
In-Reply-To: <CAF+90c-igAJ0ZFbvbuKtZyxN99y-kDr_VVm9FDcGorLcb3xWyQ@mail.gmail.com>
Date: Fri, 12 Nov 2021 17:56:22 +0100
Message-ID: <CAF+90c9GWiMYBjBZUAD72z8JXLBVKyHwAkY=jrorszUyq+M2Ow@mail.gmail.com>
To: Ben Ramsey <ramsey@php.net>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b00c5a05d09a5705"
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000b00c5a05d09a5705
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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.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=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 deprecate=
d 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 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 relea=
se
> 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

--000000000000b00c5a05d09a5705--