On Thu, May 18, 2023 at 8:55 AM Reinis Rozitis <r...@roze.lv> wrote:
> > Which begs the question of a PHP Package for PHP. Some benefits: > > > > - Written in PHP, it will allow a much wider pool of contributors than > the > scarce pool of C developers contributing to PHP source code. > > Aren't this what frameworks are for (Laravel / Yii / Symfony / Zend etc)? > I don't believe they are. What they do is try to fill the language gap by creating competing implementations for common tasks, which then led to the rise of PSR in an attempt to further address competing abstractions. We definitely can keep living like this and forget about this matter. My wish here is just to be able to address a shortcoming PHP has with its standard library. My interpretation is that the PHP standard library was born in a completely different era and was a source of unpleasantness. It is a burden of maintenance on C developers and it has very little room for mistakes since once it's embedded in the language a breaking change has a devastating impact, which led to the current state of: "if it can be done in userland, it most likely should unless there's extremely strong reason not to". The bar of improving the standard library is too high and userland does not have the ability to define one common implementation that can be used across every project. The only entity that could take a step towards improving this is the PHP project itself. Why should PHP take on such a burden? - It's a greenfield opportunity within the language. I get a vague sense that it slightly resembles Kotlin for Java or Typescript for Javascript. Such opportunity could make a huge difference. - The burden on the current contributors of internals would mostly be about RFCs and discussions. PHP developers would jump in to provide implementation and maintenance. If I'm wrong here, then the project can just die out. I like Dan's description of an RFC here: > It might be better to think of the RFC process for new features to be > a decision on "should this feature be in PHP?" rather than a "must > this feature be in PHP?". If the PHP community cannot come in together to provide the implementation of PHP code for an approved RFC, then the PHP community does not need the benefit of it. - Plenty of opportunities for mistakes. If a design/implementation turns out to be wrong, we can leverage namespaces to "fix that" while keeping backward compatibility for the language at a very low maintenance burden. - High opportunity for improved user experience. If PHP implementation of something doesn't work for your particular use case, you can just ignore it and implement your own. But if done right, we can likely address 80% of use cases with standard libraries and allow developers to leverage these implementations across every single PHP project with no extra effort for the user. - Improved perception of the language itself. This helps attract newcomers to the language and reduces the burden of learning some of the PHP quirks of its standard library. - Modernization of PHP standard offerings and a home for language improvements with a lower entry barrier Perhaps I'm just in a honeymoon trap with the idea which might be blinding me to its downsides. The only one I truly see is the amount of discussion and bikeshedding within PHP Internals until implementations land. I don't know how bad it could get and how it would affect contributors' emotional energy. But I don't expect it to be bad. I expect it to be PSR on steroids. And it would be for a limited time. There's only so much we can offer in a standard library. And then we can enjoy its benefits for many years to come. > Or PEAR? > Like that particular path_join() request is exactly > https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath > > rr I have worked with PHP for 14 years now and I know nothing about PEAR. It either says something about me or about PEAR. -- Marco Deleu
