On Mon, Nov 15, 2021 at 3:02 PM James Gilliland <firstname.lastname@example.org> wrote:> On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans <email@example.com> wrote: > > > Dear Internals, > > > > On Wed, 10 Nov 2021, Nikita Popov wrote: > > > > > On Wed, Aug 25, 2021 at 12:02 PM Nikita PopovBy design my REST API utilizes dynamic properties. I've always found it to be a feature of PHP, not a bug.
firstname.lastname@example.org> > > 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. >-- Chase Peeler email@example.com
> > By design my REST API utilizes dynamic properties. I've always found it to > be a feature of PHP, not a bug. > > -- > Chase Peeler > firstname.lastname@example.org >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
On Mon, Nov 15, 2021 at 3:11 PM Deleu <email@example.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 >> firstname.lastname@example.org >> > > 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 aroundour 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 email@example.com