On Wed, Oct 2, 2024 at 3:38 PM Larry Garfield <la...@garfieldtech.com> wrote:
> Since Jim's RFC proposal was criticized for being too vague, I hereby > offer a somewhat more prescriptive policy proposal on using 3rd party > code. (With JIm's blessing.) It's still more heuristics than rules, but I > think that's the right approach generally. It also includes a voting > mechanism to resolve edge cases when they come up. > > I'm sure we'll bikeshed it to death, but please keep an open mind about > the concept in the first place. PHP is more than just php-src, and that's > a good thing. We need to catch up with that reality, while at the same > time maintaining a reasonable neutrality about projects Internals doesn't > manage directly. > > https://wiki.php.net/rfc/third-party-code > > *Puts on trusty flame-retardant suit* > > -- > Larry Garfield > la...@garfieldtech.com > Good writeup. Although I was more of a fan of Jim's RFC which just targets the main issue of bringing up in the mailing list that PHP cannot use X because "endorsement", this is also a good alternative. My only problem with it is in the "discussion" section: Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While Laravel > and Symfony are the market leaders in PHP frameworks, and WordPress > dominates the CMS-oid market, it is a highly dynamic market, with literally > dozens of players that have reasonable use. That makes listing them in the > documentation without “playing favorites” essentially impossible, and > therefore none should be listed by name. They should also not be used > directly to build any PHP tooling, again to avoid the appearance of > endorsement. However, it may make sense to list several of them in passing > in marketing material, explicitly noting that they are just some among many > options. It's 2024. If the foundation is hiring developers to improve the language across the board (internals, docs, website, processes, marketing, visibility, etc), it makes no sense that these folks (or any volunteer for that matter) be explicitly and unquestionably denied the opportunity or conversation to modernize the system which PHP tooling is built upon. Its understandable for historical reasons that frameworks would come and go, which is why a lot of PHP systems from the 2005-2015 era usually are built with an in-house framework. But at least in my little personal context, in-house frameworks have proved themselves to be a nightmare for PHP software engineers at large. A lot of these market leaders open source frameworks are sustainable companies with a decade of proven stability, reliability and efficiency. The sole principle behind a framework is to facilitate work and this discussion point makes a clear statement that work cannot be facilitated. I am very opinionated on what is the best tool to help build PHP tooling, but it seems pretty clear to me that any framework would be better than no framework because the alternative is that a framework will be built in-house and nobody in the world will have prior experience with that one. -- Marco Deleu
