On Thu, Jul 4, 2024, at 12:37, Ken Guest wrote: > > > On Thu, 4 Jul 2024 at 07:32, Rob Landers <rob@bottled.codes> wrote: >> __ >> >> My main feedback to PSR’s is that they are fundamentally broken due to being >> outdated. The idea behind the standards is sound, but there are only a few >> PSRs that are applicable to today’s PHP. When I look at creating new >> libraries today, PSR’s are a good inspiration, but they probably shouldn’t >> be used in actual programs. Here’s a short list of outdated standards I’ve >> collected over the last couple of years: >> >> • 7 >> • 11 >> • 15 >> • 18 >> • 20 >> Most of these breakdown if you start dealing with fibers, various new scopes >> introduced by runtimes, new http standards, etc. >> >> Ergo, if you’ve run into these issues, you are likely inclined to stay as >> far away from PSR’s as reasonably possible and may have a negative view of >> them. However, for enterprise applications, PSR’s are a godsend. So they do >> have their uses, don’t get me wrong, but if you want to use technology newer >> than 2019-ish, you need to avoid them; and this is a large part of why I say >> PSR-XX isn’t a valid argument on this list. > > This is one of the reasons why we [FIG] now have the concept of PHP Evolving > Recommendations (PERs), which can be updated/evolved over time with multiple > releases - instead of having having a succession of PSRs and having to know > which one supersedes another. > > The only example of this thus far is PER-CS for Coding Standards - version 1 > being the PER equivalent of PSR-12 and version 2 of PER-CS being an update > addressing syntax in PHP that was not present when PSR-12, e.g. match, enums, > attributes and all that other wonderful stuff. > > There is no reason why any current PSR can't be replaced with a PER > equivalent - given a Working Group, time and focus. > > Except maybe PSR-8. > > > > -- > http://about.me/kenguest/
If I could have one to be a PER first, it would be the container interface (PSR-11). When it was originally worked on, there was basically one lifecycle of an object: a request. For almost all possible SAPIs, after the request ended, everything was gone. Today, we basically have multiple ones if you are using modern runtimes: 1. Environment Scope: configuration that survives execution of the program 2. Global Scope: services/entities that can exist beyond the lifetime of a request, but may or may not (depending on runtime) 3. Request Scope: services/entities that should be unique for every request. 4. Volatile Scope: services/entities that should be created every time they are injected. Right now, these are all mixed into one giant container, that may or may not be shared between requests, because that is the interface we have to work with. It isn't great :| but it works, barely. — Rob
