On Fri, May 19, 2023, 09:26 Mike Schinkel <m...@newclarity.net> wrote:
> > 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 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". > >
