Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116388
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> <CAO3MkaD9DKTrEZhrjtwY54CL0kH3cU=QUoCPju+upxZrn0eNjw@mail.gmail.com>
In-Reply-To: <CAO3MkaD9DKTrEZhrjtwY54CL0kH3cU=QUoCPju+upxZrn0eNjw@mail.gmail.com>
Date: Mon, 15 Nov 2021 15:05:28 -0500
Message-ID: <CAPKYkKyc7Cxp4qiegKdxou8GRStYPSHNO76LojP4m9fv6uWbOg@mail.gmail.com>
To: James Gilliland <neclimdul@gmail.com>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000041dc9005d0d955f4"
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000041dc9005d0d955f4
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 15, 2021 at 3:02 PM James Gilliland <neclimdul@gmail.com> wrote:

> 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?
>

By design my REST API utilizes dynamic properties. I've always found it to
be a feature of PHP, not a bug.


>
> I think this sort of change is probably for the better, but I worry about
> how disruptive this could end up being.
>


-- 
Chase Peeler
chasepeeler@gmail.com

--00000000000041dc9005d0d955f4--