Hey all On 02.10.24 21:17, Deleu wrote:
On Wed, Oct 2, 2024 at 3:38 PM Larry Garfield <la...@garfieldtech.com <mailto: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 <https://wiki.php.net/rfc/third-party-code> *Puts on trusty flame-retardant suit*-- Larry Garfieldla...@garfieldtech.com <mailto: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.
IMO the PHP website is more or less a bunch of static pages. There is not really much interaction necessary. So having a framework might not necessarily be The Thing.
I much rather see the new content to be provided via git in something like DocBook or RestructuredText and then parsed by something like PHPDocumentor based on a template into static websites.
But that's just my 0.02€
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
OpenPGP_signature.asc
Description: OpenPGP digital signature
