Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116387
MIME-Version: 1.0
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
 <CAF+90c9XwAwbA60NQgnu5btiuE_Y9n8eASnVi8TH65jK3A2C8w@mail.gmail.com> <alpine.DEB.2.23.453.2111150948120.4221@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.23.453.2111150948120.4221@singlemalt.home.derickrethans.nl>
Date: Mon, 15 Nov 2021 14:02:29 -0600
Message-ID: <CAO3MkaD9DKTrEZhrjtwY54CL0kH3cU=QUoCPju+upxZrn0eNjw@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000092bfb105d0d94ab8"
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: neclimdul@gmail.com (James Gilliland)

--00000000000092bfb105d0d94ab8
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans <derick@php.net> wrote:

> Dear Internals,
>
> On Wed, 10 Nov 2021, Nikita Popov wrote:
>
> > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> >
> > > This RFC takes the more direct route of deprecating this
> > > functionality entirely. I expect that this will have relatively
> > > little impact on modern code (e.g. in Symfony I could fix the vast
> > > majority of deprecation warnings with a three-line diff), but may
> > > have a big impact on legacy code that doesn't declare properties at
> > > all.
> > >
> >
> > I plan to open voting on this RFC soon. Most of the feedback was
> > positive, apart from the initial choice of opt-int mechanism, and that
> > part should be addressed by the switch to the
> > #[AllowDynamicProperties] attribute.
>
> The voting is now open, but I think one thing was not taken into account
> here, the many small changes that push work to maintainers of Open
> Source library and CI related tools.
>
> In the last few years, the release cadence of PHP has increased, which
> is great for new features. It however has not been helpful to introduce
> many small deprecations and BC breaks in every single release.
>
> This invariably is making maintainers of Open Source anxious, and
> frustrated as so much work is need to keep things up to date. I know
> they are *deprecations*, and applications can turn these off, but that's
> not the case for maintainers of libraries.
>
> Before we introduce many more of this into PHP 8.2, I think it would be
> wise to figure out a way how to:
>
> - improve the langauge with new features
> - keep maintenance cost for open source library and CI tools much lower
> - come up with a set of guidelines for when it is necessary to introduce
>   BC breaks and deprecations.
>
> I am all for improving the language and making it more feature rich, but
> we have not spend enough time considering the impacts to the full
> ecosystem.
>
> I have therefore voted "no" on this RFC, and I hope you will too.
>
> cheers,
> Derick
>

I appreciate that Derick. I know there have been some pretty big efforts
required for some recent php updates in Drupal. And I've mentioned in a
couple threads on Twitter but Drupal requires a pretty heavy change to
support this. It adds properties to classes _outside_ its codebase which
means none of the mitigations in the RFC apply. It was on my radar when the
vote popped up because the system in question has long been known to be
less than ideal but "php wouldn't ever remove this ancient feature right?"
and every other option is just a ton more complicated. I've talked with
some maintainers and it looks like we're going to deal with the cost of
converting the system but if this dirty hack hadn't been on our radar it
could have really hurt. Like maybe not getting the fix in place before the
next major release in time for backwards compatibility commitments bad.

So I worry what sort of earthquake this might trigger through libraries.
Like, I'm pretty sure the OpenApiGenerator templates used dynamic
properties for some things so how many little internal libraries are going
to have to be regenerated? What other lightly maintained library are people
going to be stuck waiting to update because someone's CI didn't catch the
deprecation?

I think this sort of change is probably for the better, but I worry about
how disruptive this could end up being.

--00000000000092bfb105d0d94ab8--