Re: [PHP-DEV] PHP Package for PHP
On Fri, May 19, 2023, at 6:55 PM, Robert Landers wrote: > I'd also like to add that I like the 'hands-off' approach that PHP has > taken in the past. I'm not a fan of some of the PSRs. I literally had > someone tell me a few months ago that I would never be a 'real > programmer' because I used tabs instead of spaces which is against the > PSR-12 spec (which is my only deviation from the spec, and why is that > even in the spec in the first place? :sigh:). Luckily for me, I guess, > I think I'm 'real programmer' ... even though it still feels like a > hobby (even 20 years later), but people pay me a bunch of money to do > it and people seem to like my work. As the person who has recently taken over as Editor for PER-CS (which is the new edition of PSR-12), let me state for the record that person is full of shit and you're welcome to tell them I said so. :-) That said, people really get fussy about the coding style PSRs/PER, but FIG has done way more than that, and arguably much more important things. :-) But I digress... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
I'd also like to add that I like the 'hands-off' approach that PHP has taken in the past. I'm not a fan of some of the PSRs. I literally had someone tell me a few months ago that I would never be a 'real programmer' because I used tabs instead of spaces which is against the PSR-12 spec (which is my only deviation from the spec, and why is that even in the spec in the first place? :sigh:). Luckily for me, I guess, I think I'm 'real programmer' ... even though it still feels like a hobby (even 20 years later), but people pay me a bunch of money to do it and people seem to like my work. IMHO, the downside of PHP enshrining things like PSRs is that it discourages people from 'breaking the rules', which is where true innovation comes from (IMHO). Symfony wouldn't be as fast without goto, Laravel without it's facade thing, and WordPress without its hooks. If you look at other languages like Python, Go, C#, etc, that have come up with The-One-True-Way, you'll pick up codebases and it just looks like any other codebase. It takes all the fun out it. Nobody wants to live in a house that looks like every other house. Organizations should be able to talk about variable alignment over a coffee if it drives them nuts, and not get shot down because of some spec a committee wrote ten years ago. My 2 cents... fwiw. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On Fri, May 19, 2023, at 2:02 PM, Rowan Tommins wrote: > On Fri, 19 May 2023 at 08:45, Arvids Godjuks > wrote: > >> I think this whole thread can be summarized into a single statement: >> >> "Let's integrate PSR standards into PHP core and ship those interfaces as >> part of the language" >> > > > That's one of the angles that's come up, but there are also some other > interesting ideas, a lot of which are actually independent of each other, > including: > > - implementing simple core functions in PHP rather than C > - using namespaces as a form of versioning > - having a default set of includes which can be over-ridden by user code > > > The one recurring theme I would pick up on though is a general optimism > about how much we could add, and get right. Call me cynical, but I don't > share that optimism. The main reason a lot of the things being discussed > don't already exist is not that PHP only accepts contributions in C, or > that Composer packages aren't installed by default; it's that nobody has > worked out the One True Design. > > Moving the discussion to this list rather than PHP-FIG, or PHPLeague, or > Symfony, etc, won't make that design process any easier. If anything, it > will make it harder - the stakes are higher, and the abilities for rework > and forking far more restricted. I would also note that a One True Design rarely comes from a committee-of-the-whole-who-is-mostly-disengaged. Symfony has a very clear core leadership that can Decide Things(tm), which helps to keep the design consistent. The same is true of Monolog, Guzzle, Ramsey/UUID, PHPUnit, and the rest of the "de facto standard library." In the case of FIG, we moved away from the "everyone in one big pile" approach many years ago toward dedicated, explicitly-named, explicitly-empowered working groups, and it has been a much more successful approach. (As a side note, nominations are open now for the FIG Core Committee and secretary positions, if anyone is interested.) Internals, in its current form, is structurally incapable of the design decisions that would need to be made for a "default versions of PSRs bundled with the language" initiative, regardless of whether it's written in C or PHP. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On Fri, 19 May 2023 at 08:45, Arvids Godjuks wrote: > I think this whole thread can be summarized into a single statement: > > "Let's integrate PSR standards into PHP core and ship those interfaces as > part of the language" > That's one of the angles that's come up, but there are also some other interesting ideas, a lot of which are actually independent of each other, including: - implementing simple core functions in PHP rather than C - using namespaces as a form of versioning - having a default set of includes which can be over-ridden by user code The one recurring theme I would pick up on though is a general optimism about how much we could add, and get right. Call me cynical, but I don't share that optimism. The main reason a lot of the things being discussed don't already exist is not that PHP only accepts contributions in C, or that Composer packages aren't installed by default; it's that nobody has worked out the One True Design. Moving the discussion to this list rather than PHP-FIG, or PHPLeague, or Symfony, etc, won't make that design process any easier. If anything, it will make it harder - the stakes are higher, and the abilities for rework and forking far more restricted. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] PHP Package for PHP
On Fri, May 19, 2023, 09:26 Mike Schinkel wrote: > > On May 18, 2023, at 1:34 PM, Rowan Tommins > wrote: > > On Thu, 18 May 2023 at 16:27, Deleu wrote: > >> 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. > > > > Then in what sense is it "missing"? What value would be served by placing > > an elephant logo on it, and renaming it "PHPLog™"? > > > > I know that's a bit of a sarcastic response, but it's also a serious one > - > > what would we define as the aims of a replacement for Monolog, which > aren't > > currently being served? > > > > We could guarantee it was installed with every version of PHP, but only > by > > severely restricting its release cycle, so that every PHP version had > > exactly one version of Monolog. If it remains an independently versioned > > Composer package, I can't think of much that would change. > > > > > > > > Taking the logging example, imagine we decided that, to paraphrase Dr > > Strangelove, "We can't allow a logging gap!" So we hack together a > logging > > package that's worse in every way than Monolog, but call it "official". > > Half the community will ignore it and carry on using Monolog; the other > > half won't realise that a better alternative exists, and be worse off > from > > Today. > > That statement only envisions inclusion of OR replacement for Monolog, but > not adding support to PHP core that would offer a standard way to USE > Monolog. Let me explain. > > And it is helpful logging was mentioned as an example because we can look > to other languages to see what they have done, and Go just recently did > exactly that. > > Go proposed[1] then added[2] a Structured Logging package to the Go > standard library even though there are many logging packages already > available for Go and in wide use[3], just as PHP has several logging > packages[4]. Their design doc[5] explains their rationale. > > Basically they wanted to include a common set of code that will operate on > a new standard interface. For PHP logging there is already a standard > interface; PSR-3[6], but what PHP does not have is an actual implementation > of PSR-3 can be depended on to always exists nor a common way all code can > get a PSR-3 logger. > > So rather than providing Monolog in core, provide a minimal implementation > in core — SimpleLogger maybe? — as well as the PSR-3 interfaces and PSR-3 > helper classes[7] plus a few new standard functions to always be available > in PHP. One of those functions — setLogger() maybe? — could allow users to > specify the PSR-3 logger they want to use, and many developers could choose > to use Monolog\Logger. > > Another of those functions — getLogger() maybe? — could then be called by > any PHP code to return an instance of `Psr\Log\LoggerInterface` so that all > code can depend a logger existing. If no PHP code had previously called > setLogger() then getLogger() would first instantiate a new SimpleLogger, > pass it to setLogger(), and then return that object for the caller to use. > > So what is "missing" is not the logging library per se, but instead the > plumbing that would make it possible for code from multiple different > authors working independently to all be able to write code that logs which > will still be interoperable, know that a logger will be guaranteed to be > available (it could even be a null logger), and also have the option to use > Monolog, some other PSR-3 library, or write their own new special-purpose > logger; whatever their choice. > > Said another way, the value gained by placing an elephant logo on it would > be: > > 1. Interoperability, > 2. Flexibility, and > 3. A guarantee of existence when called. > > > I actually wonder if some things in core should be removed to encourage > > userland replacements - ext/soap, for instance, and some of the data > > structures in ext/spl. > > Having a PHP core standard library could allow for some of those things to > be reimplemented in PHP but still included in PHP core. That would reduce > the need to maintain them in C, and would be a way to slowly deprecate them > for userland alternatives, ideally with some inclusion of new simple > standard interfaces and some new functions for could make working with > instances — setSOAPClient()/getSOAPClient() maybe? — to allow people to > use the built-in ones or to replace with their own. > > ext/spl could be moved to a PHP core standard library assuming doing so > was performant enough and/or new features were added to core to allow them > to be implemented in a performant manner that did not kneecap > performant-sensitive code that use them. > > > IMHO, the things that would benefit from being written in PHP then >
Re: [PHP-DEV] PHP Package for PHP
> On May 18, 2023, at 1:34 PM, Rowan Tommins wrote: > On Thu, 18 May 2023 at 16:27, Deleu wrote: >> 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. > > Then in what sense is it "missing"? What value would be served by placing > an elephant logo on it, and renaming it "PHPLog™"? > > I know that's a bit of a sarcastic response, but it's also a serious one - > what would we define as the aims of a replacement for Monolog, which aren't > currently being served? > > We could guarantee it was installed with every version of PHP, but only by > severely restricting its release cycle, so that every PHP version had > exactly one version of Monolog. If it remains an independently versioned > Composer package, I can't think of much that would change. > > > > Taking the logging example, imagine we decided that, to paraphrase Dr > Strangelove, "We can't allow a logging gap!" So we hack together a logging > package that's worse in every way than Monolog, but call it "official". > Half the community will ignore it and carry on using Monolog; the other > half won't realise that a better alternative exists, and be worse off from > Today. That statement only envisions inclusion of OR replacement for Monolog, but not adding support to PHP core that would offer a standard way to USE Monolog. Let me explain. And it is helpful logging was mentioned as an example because we can look to other languages to see what they have done, and Go just recently did exactly that. Go proposed[1] then added[2] a Structured Logging package to the Go standard library even though there are many logging packages already available for Go and in wide use[3], just as PHP has several logging packages[4]. Their design doc[5] explains their rationale. Basically they wanted to include a common set of code that will operate on a new standard interface. For PHP logging there is already a standard interface; PSR-3[6], but what PHP does not have is an actual implementation of PSR-3 can be depended on to always exists nor a common way all code can get a PSR-3 logger. So rather than providing Monolog in core, provide a minimal implementation in core — SimpleLogger maybe? — as well as the PSR-3 interfaces and PSR-3 helper classes[7] plus a few new standard functions to always be available in PHP. One of those functions — setLogger() maybe? — could allow users to specify the PSR-3 logger they want to use, and many developers could choose to use Monolog\Logger. Another of those functions — getLogger() maybe? — could then be called by any PHP code to return an instance of `Psr\Log\LoggerInterface` so that all code can depend a logger existing. If no PHP code had previously called setLogger() then getLogger() would first instantiate a new SimpleLogger, pass it to setLogger(), and then return that object for the caller to use. So what is "missing" is not the logging library per se, but instead the plumbing that would make it possible for code from multiple different authors working independently to all be able to write code that logs which will still be interoperable, know that a logger will be guaranteed to be available (it could even be a null logger), and also have the option to use Monolog, some other PSR-3 library, or write their own new special-purpose logger; whatever their choice. Said another way, the value gained by placing an elephant logo on it would be: 1. Interoperability, 2. Flexibility, and 3. A guarantee of existence when called. > I actually wonder if some things in core should be removed to encourage > userland replacements - ext/soap, for instance, and some of the data > structures in ext/spl. Having a PHP core standard library could allow for some of those things to be reimplemented in PHP but still included in PHP core. That would reduce the need to maintain them in C, and would be a way to slowly deprecate them for userland alternatives, ideally with some inclusion of new simple standard interfaces and some new functions for could make working with instances — setSOAPClient()/getSOAPClient() maybe? — to allow people to use the built-in ones or to replace with their own. ext/spl could be moved to a PHP core standard library assuming doing so was performant enough and/or new features were added to core to allow them to be implemented in a performant manner that did not kneecap performant-sensitive code that use them. > IMHO, the things that would benefit from being written in PHP then bundled > are things that are so low-level that it's hard to get them wrong; the > building blocks that the community will use to build things like Monolog > and Guzzle. Imagine all the PSR interfaces as
Re: [PHP-DEV] PHP Package for PHP
On 5/18/23 9:00 PM, Deleu wrote: On Thu, May 18, 2023 at 6:56 PM Rowan Tommins wrote: On 18 May 2023 20:15:44 BST, Deleu wrote: I meant exactly the opposite. Monolog is an example of what PHP (is missing === doesn't have enough of). There's hardly any reason to re-release it under the PHP umbrella. Monolog already won the log battle. I can't say the same for virtually anything else, to be honest. Some folks might say that Guzzle won the HTTP battle, I just disagree and think we could have something better by default Let's look at HTTP clients then. PHP is certainly lacking a good one built in. Using streams with allow_url_fopen is serviceable for fetching a page, but not much else; the curl functions are ... embarrassing. [..] On the other hand, a clean API with a much smaller feature set, which could be used on its own for simple use cases, and be the low level implementation for Guzzle, Symfony HttpClient, etc, would be extremely useful. In other words, an overhaul of the curl functions to give the same flexibility, but an API that feels more native to PHP, rather than a thin wrapper around the C functions of libcurl. Let me start from here where we agree on. We start by designing a new PHP package to wrap cURL. Bear in mind for a minute that I started this thread with the intention of lowering the barrier of getting RFC approved and the code being maintained by PHP developers. After some good amount of bikeshedding we approve the first PHP package. It is fully covered by automation tests so that future maintenance is relatively easy. It gets released under the namespace Php\8.4\Curl. I'm going to be greedy here and assume we even get it bundled inside PHP. Before PHP 8.4 gets released we also work on Php\8.4\Strings package. For the sake of argument let's pretend that within 1 month of PHP 8.4 release we discover that the Curl package was actually really bad and we decide to rework it. A new RFC is approved and we bundle a new design under Php\8.5\Curl. Meanwhile Strings was a success and no new version is warranted. So Php\8.5\Strings does not need to exist. Now both new designs are still great and Php\8.6\Curl and Php\8.6\Strings do not need to exist either. Perhaps someone raises an RFC so that PHP 8.7 will unbundle/eject Php\8.4\Curl and keep only Php\8.5\Curl inside PHP. It's a breaking change, but one that just means we now move the code to being Composer-only instead of bundled inside PHP. It's a "deprecated" package that can just exist on GitHub for backwards compatibility. A few more years go by and another RFC comes in to abandon Php\8.4\Curl from the PHP Group. This whole story, from a user standpoint, screams stability. If a project starts using Php\8.4\Curl and gets so deep into it that it's too expensive for them to upgrade, they can just keep using it without upgrading to the 8.5 counterpart while still upgrading their PHP binary. If it gets unbundled, they can just `composer require` it. If years go by and the package gets abandoned, they can still fork it and pretty much no code change would be necessary. With namespaces, PHP Packages get to do "Editions" without all of the complexity of doing editions at the engine level. Written in PHP, it can easily get ejected out of the PHP binary and still be "backward-compatible". PHP seems to be at a corner where it's best not to do anything than to make another mistake. A mistake made in the design of the language takes decades to undo. I believe we can improve the language's basic functionality this way and slowly grow into wrapping most features needed by the majority of web applications. We could start with just wrapping libcurl in a nicer API and if it works out great we could do more until one day we end up even providing a slim HTTP Client. The PHP community as a whole (regardless of which framework camp you are in) as well as newcomers could only benefit from it. PHP seems to be at a corner where it's best not to do anything than to make another mistake. A mistake made in the design of the language takes decades to undo. I think this is a bold statement about the state of PHP and should have the backing to hold it up. we could start with just wrapping libcurl in a nicer API and if it works out great we could do more until one day we end up even providing a slim HTTP Client. php and curl are two seperate "things" entaties if you will, libcurl works very well on its own. I hear you in your want to have a united community of frameworks but as of now, php is (and correct me if I am wrong in projecting this) is a community that helps to provide ways to use PHP in usefull environments. " PHP seems to be at a corner where it's best not to do anything than to make another mistake. " I think you are more on the money than you are not... but this does not mean that PHP is in anyone's pocket -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 6:56 PM Rowan Tommins wrote: > On 18 May 2023 20:15:44 BST, Deleu wrote: > > I meant exactly the opposite. Monolog is an example of what PHP (is > missing > > === doesn't have enough of). There's hardly any reason to re-release it > > under the PHP umbrella. Monolog already won the log battle. I can't say > the > > same for virtually anything else, to be honest. Some folks might say that > > Guzzle won the HTTP battle, I just disagree and think we could have > > something better by default > > > Let's look at HTTP clients then. > > PHP is certainly lacking a good one built in. Using streams with > allow_url_fopen is serviceable for fetching a page, but not much else; the > curl functions are ... embarrassing. [..] On the other hand, a clean API with a much smaller feature set, which could > be used on its own for simple use cases, and be the low level > implementation for Guzzle, Symfony HttpClient, etc, would be extremely > useful. In other words, an overhaul of the curl functions to give the same > flexibility, but an API that feels more native to PHP, rather than a thin > wrapper around the C functions of libcurl. Let me start from here where we agree on. We start by designing a new PHP package to wrap cURL. Bear in mind for a minute that I started this thread with the intention of lowering the barrier of getting RFC approved and the code being maintained by PHP developers. After some good amount of bikeshedding we approve the first PHP package. It is fully covered by automation tests so that future maintenance is relatively easy. It gets released under the namespace Php\8.4\Curl. I'm going to be greedy here and assume we even get it bundled inside PHP. Before PHP 8.4 gets released we also work on Php\8.4\Strings package. For the sake of argument let's pretend that within 1 month of PHP 8.4 release we discover that the Curl package was actually really bad and we decide to rework it. A new RFC is approved and we bundle a new design under Php\8.5\Curl. Meanwhile Strings was a success and no new version is warranted. So Php\8.5\Strings does not need to exist. Now both new designs are still great and Php\8.6\Curl and Php\8.6\Strings do not need to exist either. Perhaps someone raises an RFC so that PHP 8.7 will unbundle/eject Php\8.4\Curl and keep only Php\8.5\Curl inside PHP. It's a breaking change, but one that just means we now move the code to being Composer-only instead of bundled inside PHP. It's a "deprecated" package that can just exist on GitHub for backwards compatibility. A few more years go by and another RFC comes in to abandon Php\8.4\Curl from the PHP Group. This whole story, from a user standpoint, screams stability. If a project starts using Php\8.4\Curl and gets so deep into it that it's too expensive for them to upgrade, they can just keep using it without upgrading to the 8.5 counterpart while still upgrading their PHP binary. If it gets unbundled, they can just `composer require` it. If years go by and the package gets abandoned, they can still fork it and pretty much no code change would be necessary. With namespaces, PHP Packages get to do "Editions" without all of the complexity of doing editions at the engine level. Written in PHP, it can easily get ejected out of the PHP binary and still be "backward-compatible". PHP seems to be at a corner where it's best not to do anything than to make another mistake. A mistake made in the design of the language takes decades to undo. I believe we can improve the language's basic functionality this way and slowly grow into wrapping most features needed by the majority of web applications. We could start with just wrapping libcurl in a nicer API and if it works out great we could do more until one day we end up even providing a slim HTTP Client. The PHP community as a whole (regardless of which framework camp you are in) as well as newcomers could only benefit from it. -- Marco Deleu
Re: [PHP-DEV] PHP Package for PHP
> On May 18, 2023, at 10:27 AM, Rowan Tommins wrote: > > 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 > > 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. There is at least a 3rd way. There could be server-wide installs with site-root overrides similar to how .htaccess works with Apache where a `.php` file (or some other name) in the site root could be used to provide overrides for the standard PHP library to allow sites to fix bugs, use a newer version, etc. This would allow site owners to resolve PHP standard library related issues with sites on managed servers where the managed host will not allow server-wide install to be modified. > Composer seems to be serving the community pretty well for a lot of > functionality. Except for Composer's lack of ability — by its very nature — to provide a single "baseline" that everyone can expect, a benefit of PEAR you noted above. > On May 18, 2023, at 10:43 AM, Reinis Rozitis wrote: > > There is usually the argument - "if this is not in core no one (people on > shared environments/hosting) won't be able to use it" and so on.. Many orgs prefer managed hosting so as not to have to pay for system administer expertise on staff, and few (any?) managed hosts will modify their installs to include more than the few highly popular extensions from PECL. > The counter to that are things like Imagick / redis / memcache(d) / APCu > which are vastly popular but still live outside core (obviously those are not > language rather than engine features). The list of extensions managed hosts will consider installing is so small — compared to the hundreds (1000s?) of extensions they will not — so pointing to the few outliers that can live outside core as evidence of developer's ability to address their needs with them is much like arguing the US Constitution can be amended to solve existing political problems. Technically both statements are correct, but practically speaking neither are realistic approaches to solving current day needs. OTOH, a standard library in core written in PHP that could allow for polyfills for future C-in-core changes, a lower bar for implementing additions to core (and thus a way to expand those who can actually contribute to core), and a starting place for anything that could be written in PHP to be written in PHP so as not to require updating and testing C code seems to have many benefits. #jmtcw -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On 18 May 2023 20:15:44 BST, Deleu wrote: > I meant exactly the opposite. Monolog is an example of what PHP (is missing > === doesn't have enough of). There's hardly any reason to re-release it > under the PHP umbrella. Monolog already won the log battle. I can't say the > same for virtually anything else, to be honest. Some folks might say that > Guzzle won the HTTP battle, I just disagree and think we could have > something better by default Let's look at HTTP clients then. PHP is certainly lacking a good one built in. Using streams with allow_url_fopen is serviceable for fetching a page, but not much else; the curl functions are ... embarrassing. On the other hand, Guzzle has gone through 7 major version bumps in 12 years, presumably believing that each improvement justified the disruption to users. And even then, as you point out, Symfony decided to write their own HttpClient component. Clearly, they didn't do that because they didn't know Guzzle existed; presumably, they thought it still wasn't good enough. An extension or library fully bundled with PHP would have no hope of competing with that. A major version could only be made every 5 years, and even then breaking changes have to be minimised, so we would really have one chance to somehow improve on what others have spent years refining. On the other hand, a clean API with a much smaller feature set, which could be used on its own for simple use cases, and be the low level implementation for Guzzle, Symfony HttpClient, etc, would be extremely useful. In other words, an overhaul of the curl functions to give the same flexibility, but an API that feels more native to PHP, rather than a thin wrapper around the C functions of libcurl. Whether it would make sense to do that in PHP, I'm not so sure. It would mean that any fundamentally new feature would need implementing twice: once in C, in the existing clunky API, then again in PHP, to wrap it into a different style. On the other hand, it would make polyfilling the new API trivial, and have a wider pool of contributors who could work on it - as long as they didn't hit a limitation that needed to be fixed in the C layer. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 2:35 PM Rowan Tommins wrote: > On Thu, 18 May 2023 at 16:27, Deleu wrote: > > 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. > > > > > Then in what sense is it "missing"? What value would be served by placing > an elephant logo on it, and renaming it "PHPLog™"? > I meant exactly the opposite. Monolog is an example of what PHP (is missing === doesn't have enough of). There's hardly any reason to re-release it under the PHP umbrella. Monolog already won the log battle. I can't say the same for virtually anything else, to be honest. Some folks might say that Guzzle won the HTTP battle, I just disagree and think we could have something better by default, such as Python's `request` Library, but I can also see such controversy being lost and leaving PHP without an HTTP Client built-in. That would be a matter for each individual RFC. > > 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. > > > > > I don't think PHP's decision-making process can be held up as a shining > example of good governance, in contrast to everyone else's anarchy. I don't > know much about Laravel's governance, but I am quite sure every change is > discussed and iterated on before release. In fact, they probably have a > whole bunch of standards and processes that PHP is lacking, and would have > to invent to make any new library a success. > I didn't mean anything about PHP's governance, to be honest. I am, however, very aware of the community battle around frameworks. I like Laravel's Arr class, but there are PHP developers that hate all things Laravel. What PHP governance brings here is that if it can't be agreed on, it won't be included. So perhaps an RFC discussing PHP's Array functions could end up taking some of Laravel's implementations or none. My point here was mostly about the fact that a PHP Standard Package addition going through PHP RFC has a lower entry barrier compared to built in C, but a higher entry level than anybody in the PHP community creating a package they personally like for themselves. The combined experience of internals participants is at least pretty good to bring a lot of perspectives. -- Marco Deleu
Re: [PHP-DEV] PHP Package for PHP
Hi Marco On Thu, May 18, 2023 at 7:35 PM Rowan Tommins wrote: > > On Thu, 18 May 2023 at 16:27, Deleu wrote: > > 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. > > > > > Then in what sense is it "missing"? What value would be served by placing > an elephant logo on it, and renaming it "PHPLog™"? > > I know that's a bit of a sarcastic response, but it's also a serious one - > what would we define as the aims of a replacement for Monolog, which aren't > currently being served? > > We could guarantee it was installed with every version of PHP, but only by > severely restricting its release cycle, so that every PHP version had > exactly one version of Monolog. If it remains an independently versioned > Composer package, I can't think of much that would change. I fully agree with Rowan. These packages have had many years to get to where they are, and are maintained by capable people. Putting an official stamp on them doesn't make them qualitatively better. I could see an argument being made for bundling them with PHP so that Composer is not required, but that does not seem smart for large libraries that need the freedom to evolve. I'm absolutely in favor for a more complete standard library in terms of basic operations, e.g. better iterator support. > > 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. > > > > > I don't think PHP's decision-making process can be held up as a shining > example of good governance, in contrast to everyone else's anarchy. I don't > know much about Laravel's governance, but I am quite sure every change is > discussed and iterated on before release. In fact, they probably have a > whole bunch of standards and processes that PHP is lacking, and would have > to invent to make any new library a success. Moreover, I believe the main barrier for adding new functions to PHPs standard library is not C but the RFC process itself. "Trial and error" is much easier than making 50+ people agree on the correct solution on the first try. I suppose something we could try is an "official but experimental" Composer package for testing new classes/functions for the standard library before stabilizing them and rewriting them in C. Maybe this could prevent some of the bike-shedding. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023, at 5:34 PM, Rowan Tommins wrote: > I actually wonder if some things in core should be removed to encourage > userland replacements - ext/soap, for instance, and some of the data > structures in ext/spl. > > IMHO, the things that would benefit from being written in PHP then bundled > are things that are so low-level that it's hard to get them wrong; the > building blocks that the community will use to build things like Monolog > and Guzzle. Another related prior: There's been on and off discussion for some time about moving stdlib C functions into PHP, and relying on preloading and JIT to make them fast. So far that hasn't happened, mainly because when someone has tried it out (mainly Nikita), it turned out to not be as fast as the existing C versions. I think there's a couple of different categories of library-esque code that need to be considered: 1. Low-level tooling that pretty much has to be in C to work correctly. This is pretty well covered already. Examples here are things like ext/curl, ext/pdo, streams, reflection, etc. 2. Application level tooling that almost every app needs. Logging is the obvious example here. 3. Base functionality that is notably faster in C than PHP. Here I include things like array_map(), array_reduce(), strlen(), etc. Much of those could be done in user-space, but there's an appreciable performance benefit to them being native in C. The new Random extension, too, *could* have been implemented in user-space, but would have been vastly slower. 4. Base functionality that is not notably faster in C, but is still considered "basic table stakes" for the type system. iterator_to_array(), for instance, could absolutely be implemented in user space, and probably wouldn't be any slower, but it's such a basic part of working with iterables that it would be an incomplete product to not have it. I would put str_contains() in the same category; it offers no real benefit other than 100% guaranteed presence, but that's enough in some cases. 5. Functionality that is often used, but not always, and gets no significant benefit from being in C. Those boundaries are a bit squishy, of course, with lots of edge cases. Personally, I don't think category 2 should be in the stdlib. That might have made sense 20 years ago, but between Composer and PHP-FIG, I don't think the argument is that compelling. Similarly, category 5 is best left to user-space. Category 1, obviously, should at least be PECL, but often in php-src standard. The tricky questions relate to what qualifies as "base functionality" and "basic table stakes", as well as how much of a performance improvement is necessary to justify inclusion (categories 3 and 4). There's also questions of historical precedent, but PHP's historical precedent is a total mess in most cases so that's not as strong an argument. :-) As an example, ramsey/uuid is the standard library for UUID generation. It seems to work pretty well in user-space. However, one could argue that it's "common enough" that it should be universally available. Maybe. A C implementation would undoubtedly be faster than in PHP but... by how much? If it were 10% faster, would that justify inclusion in core? How about 30% faster? 3x faster than user-space? Where is the cutoff for "enough performance different" and "common enough usage"? We have no consensus on that right now, nor do we even ask the question so directly in most cases. We should be, though, lest we just fall back on personal emotional responses. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On Thu, 18 May 2023 at 16:27, Deleu wrote: 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. > Then in what sense is it "missing"? What value would be served by placing an elephant logo on it, and renaming it "PHPLog™"? I know that's a bit of a sarcastic response, but it's also a serious one - what would we define as the aims of a replacement for Monolog, which aren't currently being served? We could guarantee it was installed with every version of PHP, but only by severely restricting its release cycle, so that every PHP version had exactly one version of Monolog. If it remains an independently versioned Composer package, I can't think of much that would change. > 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. > I don't think PHP's decision-making process can be held up as a shining example of good governance, in contrast to everyone else's anarchy. I don't know much about Laravel's governance, but I am quite sure every change is discussed and iterated on before release. In fact, they probably have a whole bunch of standards and processes that PHP is lacking, and would have to invent to make any new library a success. > ... it takes away all the time and energy collectively spent in evaluating > options and their reputations. > I don't think that's really true; reputations have to be earned, and maintained. Taking the logging example, imagine we decided that, to paraphrase Dr Strangelove, "We can't allow a logging gap!" So we hack together a logging package that's worse in every way than Monolog, but call it "official". Half the community will ignore it and carry on using Monolog; the other half won't realise that a better alternative exists, and be worse off from today. I actually wonder if some things in core should be removed to encourage userland replacements - ext/soap, for instance, and some of the data structures in ext/spl. IMHO, the things that would benefit from being written in PHP then bundled are things that are so low-level that it's hard to get them wrong; the building blocks that the community will use to build things like Monolog and Guzzle. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] PHP Package for PHP
Hi On 5/18/23 18:13, tag Knife wrote: An extension of this, Looking on packagist. The namespace PHP is reserved, in collaboration with PHP, Composer and Packagist. Official PHP packages can use the /PHP/... root namespace. And can be published on packagist under the PHP namespace To my understanding in the https://wiki.php.net/rfc/namespaces_in_bundled_extensions RFC it was agreed *not* to use the PHP namespace and instead create appropriate top-level namespaces. The new random implementation in PHP 8.2 is already "relying" on that RFC: Everything is sitting in Random\* and that namespace is now effectively reserved for it. There was also this proposal (that did not yet go anywhere) to introduce the iterable\* top-level namespace: https://externals.io/message/118896#118896 Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 11:43 AM Reinis Rozitis wrote: > > I have worked with PHP for 14 years now and I know nothing about PEAR. > It either says something about me or about PEAR. > > Then the next logical question would be do you know what PECL is? :) > > But to be short my point is - before attempting to get new function(ality) > in core it (seems to me) that more realistic if you really want to achieve > that is at least by presenting some kind of working base blocks especially > when there are all the means to extend the language both on low level > (being an extension) or a pure-php package in any of the existing channels > (composer / push for repopulation of PEAR? etc). > My wish here is not to present a new functionality to core, but rather start a project which lowers the barrier for getting basic things into core. Sure, I could write a new Str class and fix all the problems I think the `str` and `str_` lib has. In fact, everyone can do that [1][2][3][4]. PHP current state actually encourages the language to have multiple competing implementations for the same thing because some past decisions are hard to be fixed and introducing things to the language are also hard. The competition and the diversity addressing all sort of problems is a strength in the PHP Community, but also a weakness in PHP's ability to provide a bare minimum that help newcomers to get started and veterans to only reach for deviation when it is made necessary. > > There is usually the argument - "if this is not in core no one (people on > shared environments/hosting) won't be able to use it" and so on.. The > counter to that are things like Imagick / redis / memcache(d) / APCu which > are vastly popular but still live outside core (obviously those are not > language rather than engine features). > > rr > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php I wouldn't argue in favour or against shared hosting. I haven't used that in a decade so I'm really not the best person to talk about that universe. If someone were to create a PHP Extension to rewrite some of PHP's functionality and/or cover PHP's standard library gaps, I know I wouldn't spend a minute of my time looking into it or installing it. I imagine that it would take many years until someone could actually build up a reputation and a library quality until it could start being considered for adoption. [1] https://github.com/spatie/string [2] https://laravel.com/api/9.x/Illuminate/Support/Str.html [3] https://symfony.com/doc/current/components/string.html [4] https://github.com/azjezz/psl/tree/next/src/Psl/Str -- Marco Deleu
Re: [PHP-DEV] PHP Package for PHP
An extension of this, Looking on packagist. The namespace PHP is reserved, in collaboration with PHP, Composer and Packagist. Official PHP packages can use the /PHP/... root namespace. And can be published on packagist under the PHP namespace https://packagist.org/packages/php/ -- Note this URL CURRENTLY redirects 404 not found as nothing has been published under this namespace.
Re: [PHP-DEV] PHP Package for PHP
> > The work to get started seems to be about: > > 1- Getting an RFC to approve this idea itself > 2- Getting a repository to host the PHP package code. > 3- CI/CD > 4- Release Management > 5- Versioning Strategy > 6- Package naming convention > 7- Distribution strategy (single package vs multiple sub-packages) > 8- PHP developers and community contributions > > Anything I'm missing? Thoughts? > I'm also wondering if we should be looking at including composer as a default install of PHP. I remember there being some discussions about it and generally a positive outcome, but then nothing further being done. We PHP would do follow this approach providing composer package manager as default with every future php release, should be a requirement.
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 11:27 AM Rowan Tommins wrote: > On Thu, 18 May 2023 at 14:12, Deleu 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
RE: [PHP-DEV] PHP Package for PHP
> I have worked with PHP for 14 years now and I know nothing about PEAR. It > either says something about me or about PEAR. Then the next logical question would be do you know what PECL is? :) But to be short my point is - before attempting to get new function(ality) in core it (seems to me) that more realistic if you really want to achieve that is at least by presenting some kind of working base blocks especially when there are all the means to extend the language both on low level (being an extension) or a pure-php package in any of the existing channels (composer / push for repopulation of PEAR? etc). There is usually the argument - "if this is not in core no one (people on shared environments/hosting) won't be able to use it" and so on.. The counter to that are things like Imagick / redis / memcache(d) / APCu which are vastly popular but still live outside core (obviously those are not language rather than engine features). rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Package for PHP
On Thu, 18 May 2023 at 14:12, Deleu 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 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]
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 3:07 AM Deleu wrote: > Hi folks! > > Reading through https://externals.io/message/120323#120326 and > https://externals.io/message/120323#120332, it reminded me of a few times > I've seen similar debates on internals about "why not do this on userland?" > and the consensus seems to be inclined to only take the maintenance burden > of internals function if there's strong justification for it regardless of > whether there's consensus of being useful or not. > > 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. > - Being official means it inherits the trust PHP already has > - Green field development in this day and age often comes with a great set > of automation tests that drastically lowers the maintenance burden > - Possibility to standardize a lot of common code that has countless > userland implementations > - If we make a mistake of implementing a bad design, the worst thing might > be that we "wasted" a good word in a function or class name. As long as > test coverage is there we can probably just keep it running for many years > with little negative impact other than "yeah, PHP did a bad job at X". > > Such a project could benefit from the RFC process already in-place and > voters could take into consideration the lower maintenance burden when > voting for something that they think it's useful. > One relevant downside is that internals might get flooded with RFCs for > filling up some common functionalities for a few years until it dials down > a bit. > It may also lead to re-discussing PHP's entire standard library. > > The work to get started seems to be about: > > 1- Getting an RFC to approve this idea itself > 2- Getting a repository to host the PHP package code. > 3- CI/CD > 4- Release Management > 5- Versioning Strategy > 6- Package naming convention > 7- Distribution strategy (single package vs multiple sub-packages) > 8- PHP developers and community contributions > > Anything I'm missing? Thoughts? > > -- > Marco Deleu > A few more benefits: - an official php polyfill package to be forward compatible with new classes/functions/constants for core php - popular features could eventually be ported to C if it gives a benefit in performance, or if they are really popular - applications with slower upgrade cycles would have less effort implementing new php features
Re: [PHP-DEV] PHP Package for PHP
On Thu, May 18, 2023 at 8:55 AM Reinis Rozitis 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
RE: [PHP-DEV] PHP Package for PHP
> 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)? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP Package for PHP
Hi folks! Reading through https://externals.io/message/120323#120326 and https://externals.io/message/120323#120332, it reminded me of a few times I've seen similar debates on internals about "why not do this on userland?" and the consensus seems to be inclined to only take the maintenance burden of internals function if there's strong justification for it regardless of whether there's consensus of being useful or not. 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. - Being official means it inherits the trust PHP already has - Green field development in this day and age often comes with a great set of automation tests that drastically lowers the maintenance burden - Possibility to standardize a lot of common code that has countless userland implementations - If we make a mistake of implementing a bad design, the worst thing might be that we "wasted" a good word in a function or class name. As long as test coverage is there we can probably just keep it running for many years with little negative impact other than "yeah, PHP did a bad job at X". Such a project could benefit from the RFC process already in-place and voters could take into consideration the lower maintenance burden when voting for something that they think it's useful. One relevant downside is that internals might get flooded with RFCs for filling up some common functionalities for a few years until it dials down a bit. It may also lead to re-discussing PHP's entire standard library. The work to get started seems to be about: 1- Getting an RFC to approve this idea itself 2- Getting a repository to host the PHP package code. 3- CI/CD 4- Release Management 5- Versioning Strategy 6- Package naming convention 7- Distribution strategy (single package vs multiple sub-packages) 8- PHP developers and community contributions Anything I'm missing? Thoughts? -- Marco Deleu
