Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

This is only part of a thread. view whole thread
  116387
November 15, 2021 20:02 neclimdul@gmail.com (James Gilliland)
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 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.
  116388
November 15, 2021 20:05 chasepeeler@gmail.com (Chase Peeler)
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 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
  116389
November 15, 2021 20:11 deleugyn@gmail.com (Deleu)
> > By design my REST API utilizes dynamic properties. I've always found it to > be a feature of PHP, not a bug. > > -- > Chase Peeler > chasepeeler@gmail.com >
I am in the unfortunate position of inheriting a system with such REST API design. I can never build new REST APIs to replace the old ones because nobody can ever know how many combinations of possible input parameters there are. -- Marco Aurélio Deleu
  116392
November 15, 2021 20:39 chasepeeler@gmail.com (Chase Peeler)
On Mon, Nov 15, 2021 at 3:11 PM Deleu <deleugyn@gmail.com> wrote:

> By design my REST API utilizes dynamic properties. I've always found it to >> be a feature of PHP, not a bug. >> >> -- >> Chase Peeler >> chasepeeler@gmail.com >> > > I am in the unfortunate position of inheriting a system with such REST API > design. I can never build new REST APIs to replace the old ones because > nobody can ever know how many combinations of possible input parameters > there are. > > Our inputs and outputs are both well defined. I've built a framework around
our entities that convert them into API payloads - attributes (symfony, but eventually we might update it to use native attributes) define what fields are visible based on user and whether it's the short (e.g. part of a collection) or full version. The thing is that occasionally we'll have a payload to return that requires additional attributes. Dynamic properties allow us to just tack that on to the existing entity without having to define it as a property on the entity (outside of the one use case the property isn't needed and it definitely doesn't correspond to a database column).
> -- > Marco Aurélio Deleu >
-- Chase Peeler chasepeeler@gmail.com