> On May 18, 2023, at 1:34 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > On Thu, 18 May 2023 at 16:27, Deleu <deleu...@gmail.com> 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. > > <snip> > > 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 well as default simple implementations for each and where applicable a set of functions to set and get those instances to be included in a PHP standard core library. If those were implemented in a PHP standard core library that there might even be motivation to develop new PSR interfaces derived from existing best practices in the wild, as right now that useful effort seems to have stalled. For example, I could see an interface and default implementation for working with ChatGPT like AI being something that people might want to look into in the near future. Again, the value IMO for having a PHP core standard library is not necessarily about being able to add functionality, but to add code that can enable code from multiple developers to work independently yet inter-operably with new or existing functionality out in the wild. Said another way, don't think of is as a Core VS. Composer, think of it as Core AND Composer. -Mike P.S. I know this thread was motivated by desire to allow PHP functions to be added to core, and I won't argue that would not be a nice-to-have option, but I think the real value would be to include interfaces, simple implementations and related functions that could enable and encourage interoperability across PHP code written by different authors independently. And having that latter would certainly not preclude the former, from time to time. [1] https://github.com/golang/go/issues/56345 [2] https://pkg.go.dev/golang.org/x/exp/slog [3] https://blog.logrocket.com/5-structured-logging-packages-for-go/ [4] https://www.loggly.com/ultimate-guide/php-logging-libraries/ [5] https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md [6] https://www.php-fig.org/psr/psr-3/ [7] https://packagist.org/packages/psr/log -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
