On Mon, Aug 26, 2024 at 3:12 PM Bob Weinand <bobw...@hotmail.com> wrote:
> Thanks for bringing this up - I also suggest that we make this a binary > choice - either we adopt the proposed language or its opposite. > > I.e. a rejection of this should codify that statement in the negative. > > I do in particular reject the notion that we should document third-party > projects (usage for our infra is fine). > > The point of the PHP documentation is to describe the PHP runtime and PECL > extensions, which are both officially distributed through php.net. > > Anything not related to these does not belong into the manual, much less > into core documentation (like language/oop5 autoload.xml, to take the > example from https://github.com/php/doc-en/pull/3677/files). > > Changing this current unwritten rule is an invitation to implicitly > promote specific projects. The question is really where does it end? Would > we for example also mention PSRs as "widely followed guidelines for > interoperability" or something? It's a strong invitation for some scope > creep. > > As such I strongly condemn the idea of inclusion of this guideline. > > There are, ultimately, enough ways for people to learn about the PHP > ecosystem, the php.net documentation is none of them. If I go to php.net, > it's because I want to learn about the runtime, not its ecosystem. > > > Bob > Since your message was somewhat ambiguous to me, I would like to take this opportunity to request clarification from Jim. I read this RFC as an opportunity to allow community-driven PHP projects to be embraced when it suits PHP's internals needs. For instance, I remember a few years ago a conversation about rebuilding the php.net website. The current "unwritten" rule was used to impose that a new PHP website could not use any existing PHP Framework as to not "endorse" any particular project. Same thing goes for the RFC Voting process, PSRs, Composer, etc. In a way, I agree with Bob's take that the php.net documentation should not be used to *document* 3rd-party tooling, but my interpretation of the RFC has nothing to do with documenting 3rd-party tools but instead its about mentioning or even relying on them. Current discussion about Generics going on talks a lot about phpstan and psalm and whatever comes out of the work put into Generics, I would definitely be in favour of PHP docs mentioning how Generics is already present today with those tools. Current work-in-progress from the Foundation in regards to revamping pecl involves (as far as I know) providing PHP Extensions via Composer which would be something that said "unwritten" rule could be mentioned for opposing such approach. There's also PHP community members that would be willing to work on a new RFC automation tool to improve on the process that has recently been mentioned as "suboptimal" [1]. Such community members would certainly opt to build this upon Symfony, Laravel, Slim or anything more convenient than vanilla PHP and such "unwritten" rule keeps us chained to suboptimal infrastructure. [1] https://externals.io/message/124843#124860 -- Marco Deleu
