Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116333
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> <CAPKYkKxTT3PVjDtEaT30tO-5BUer15kdYH2-7OTcj0r8ub_1_w@mail.gmail.com>
In-Reply-To: <CAPKYkKxTT3PVjDtEaT30tO-5BUer15kdYH2-7OTcj0r8ub_1_w@mail.gmail.com>
Date: Fri, 12 Nov 2021 18:53:28 +0100
Message-ID: <CADK1yXKSYy8eFodCQPUTwMqbhfiXsMVy0838VXr_aCBva4LuqA@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000c686305d09b25d7"
Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
From: deleugyn@gmail.com (Deleu)

--0000000000000c686305d09b25d7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 12, 2021 at 6:47 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> 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.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 larg=
e
> BC
> > >>> break for, and it should wait until the last in the 8.x series befo=
re
> > 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 depr=
ecated 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 tha=
n
> to
> > >> 8.4, which would be directly before a major version with limited tim=
e
> to
> > >> act. Now, we don't usually tend to optimize for "time of deprecation=
"
> > >> because that requires planning deprecations many years in advance, b=
ut
> > 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 th=
at
> > the
> > > deprecation warning is really helpful for updating your code. It tell=
s
> > you
> > > exactly which property on which class is being created dynamically, s=
o
> > 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 bitte=
n
> > 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 agr=
ee
> that if it is going to be removed, the more time/versions that exists
> between deprecation and removal, the better.
> --
> Chase Peeler
> chasepeeler@gmail.com
>


I agree with previous replies and would even go as further to say that it
is better to try and avoid deprecation on the last version of a PHP Series.
I like this deprecation, but I also think it's a pretty big deprecation to
happen only 1 year before it's actual removal. Deprecating it now means
people will have at least 3 years to adjust to it. Recently Laravel also
made the same changes that PHPUnit did to stop converting deprecations into
fatal errors so that users can still use deprecated code if they need more
time to accommodate.

--=20
Marco Aur=C3=A9lio Deleu

--0000000000000c686305d09b25d7--