Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116332
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>
 <CAF+90c9GWiMYBjBZUAD72z8JXLBVKyHwAkY=jrorszUyq+M2Ow@mail.gmail.com> <e707e99c-6fe8-4a14-89f5-2e11b2de1fd4@www.fastmail.com>
In-Reply-To: <e707e99c-6fe8-4a14-89f5-2e11b2de1fd4@www.fastmail.com>
Date: Fri, 12 Nov 2021 12:47:17 -0500
Message-ID: <CAPKYkKxTT3PVjDtEaT30tO-5BUer15kdYH2-7OTcj0r8ub_1_w@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000095b60c05d09b0db9"
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000095b60c05d09b0db9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 12, 2021 at 12:44 PM Larry Garfield <larry@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.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.co=
m
> >
> >>> 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 deprec=
ated 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
> 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 i=
n
> > 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 i=
s
> > reasonably clean under static analysis. At the same time, this change i=
s
> > 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 runnin=
g
> 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 a=
s
> 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.
--=20
Chase Peeler
chasepeeler@gmail.com

--00000000000095b60c05d09b0db9--