On Thu, May 18, 2023 at 11:27 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On Thu, 18 May 2023 at 14:12, Deleu <deleu...@gmail.com> wrote: > > > > 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 > > > > > > I have worked with PHP for 14 years now and I know nothing about PEAR. It > > either says something about me or about PEAR. > > > > > For many years PEAR was the official package repository for PHP. The client > was shipped with every install of PHP, and still serves as the basis for > PECL, the official distribution for PHP extensions. > > From the point of most users, it has been entirely replaced by Composer, > and I think some of the reasons for that are very relevant to this > discussion: > > - PEAR required a package to be installed globally on a server; Composer > allows (and encourages) it to be local to a particular project > - PEAR was a "walled garden" - you had to request permission to publish a > new package, or take over an existing one; Composer is a "bazaar" - anyone > can publish a package to Packagist, and projects can be forked > - PEAR tried to be a cohesive ecosystem - it had a unified coding standard, > and a strong policy of package interoperability, aiming for a common "feel" > across all packages; Composer leaves developers to combine packages however > they want > > On the one hand, PEAR was a single "baseline" that everyone expected; on > the other hand, packages tended to be slow to adapt to new needs and > fashions, and inflexible to different environments. So instead, people > moved to: > > - Frameworks; which themselves have mostly adopted a "component-based" > approach interoperating via Composer packages > - Non-framework groups like The League of Extraordinary Packages > https://thephpleague.com/ > - Single packages that have become de facto standards - large projects like > Guzzle and Monolog; and smaller utilities that do one task well, like > Ramsey/UUID > Thanks for the history lesson, this is super useful information, indeed. Monolog is a great example of what PHP is missing - a single library for a purpose. I have never worked with any other library besides Monolog and I never worked on any project which didn't have it installed. Perhaps my bubble might be a limiting factor here, but I get a feeling that Monolog is considered to be The Logging PHP Library. Guzzle is a near 2nd, but not quite there, especially after Symfony built their own HTTP Client and further drove the community split. Laravel has an amazing `Arr` class that wraps most of PHP's array_* standard library and I love it and find it amazing, but it's a niche community within PHP. Newcomers might get exposed to community debates[1] that end up driving them away from taking advantage of a better array_* suite. Laravel's `Arr` class also didn't get scrutinized by PHP RFC so there's no way to know whether it's all good, some good or all bad. > > There are two ways I can see a "standard PHP package" working: > > - As a server-wide install, part of the distributed PHP. That inherits all > the downsides of PEAR, but might be appropriate for a fairly small subset > of really low-level functions. > - As a set of Composer packages, managed completely outside the PHP > lifecycle, in which case it's not clear how it would be different from all > the packages that are already out there. > > Bottom line, I think there is some merit in having part of the standard > library be written in PHP rather than C, but we'd still want to be very > conservative in what went in there, because most of the downsides of > locking it to the PHP release cycle would still be there, and Composer > seems to be serving the community pretty well for a lot of functionality. > > Regards, > -- > Rowan Tommins > [IMSoP] I also see both options for this to work, but honestly I have no strong feelings either way. For me it's pretty clear that a set of Composer packages offering standard libraries under the PHP namespace and limited to what gets approved by RFCs would be a lot different from all the packages that are all there because it takes away all the time and energy collectively spent in evaluating options and their reputations. We can get started with what PHP offers by default and delay the evaluation process until the PHP standard library no longer supports the use case. It's the standard option and is covered by PHP's reputation. If your use case is not standard, you might reach for a community-provided library that enhances the standard library needs or build your own instead of always having to use a community-provided library or build your own. I also like the option of bundling it together with PHP, but that would take some effort on PHP's Core Developers and I'd rather take the benefits of having a PHP Standard Composer Package than to risk not having it because it increases Core Developers' maintenance burden. The nice thing about it is that if the idea works out great, a new RFC can be written to bring the package into core and have that decision voted individually on its own merits. Finally, one awesome aspect I also see is that when time comes to deprecate, abandon or "fix" design flaws in the PHP Standard Library, regardless of whether it's bundled or a composer package, it can always be ejected into a composer package. If 20 years from now there's a major "legacy" project with a heavy dependency on something that PHP decides to deprecate, they can just fork the package and embed it with their application. One can argue that maybe we can do that today as long as we write a custom PHP extension, but then comes the burden of PHP developers having to know how to develop C and use PHP's extension system to try and bring back functionality that was dropped from the language. -- Marco Deleu
