Re: Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

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/