Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120358
MIME-Version: 1.0
References: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
 <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv> <CADK1yXK4U=-POE2h5zu5de1NS0pQE7Rppa6QNxboEeRuOMDYJw@mail.gmail.com>
 <CALKiJKpyfhKB8yQ2us5LyUsk7RfM1fdgLCNHDpcAL6vHeXgD-A@mail.gmail.com>
 <CADK1yXJPyAes4UeNSTasX_ri4yJrLfSVhg7W=RL1iYknBRT6Wg@mail.gmail.com>
 <CALKiJKq+0fOc7=8zX_gZWQ395jHV3BUKKMEXNwc5yZEbmJEC_A@mail.gmail.com> <3DD7832A-5A32-4F21-88F9-FA95B172013D@newclarity.net>
In-Reply-To: <3DD7832A-5A32-4F21-88F9-FA95B172013D@newclarity.net>
Date: Fri, 19 May 2023 10:45:46 +0300
Message-ID: <CAL0xaBFJjENYv0d3V5x2FUExJbB64pD=anT6oBTPqwNczNsGsg@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000927a4905fc071ccf"
Subject: Re: [PHP-DEV] PHP Package for PHP
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000927a4905fc071ccf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 19, 2023, 09:26 Mike Schinkel <mike@newclarity.net> wrote:

> > On May 18, 2023, at 1:34 PM, Rowan Tommins <rowan.collins@gmail.com>
> wrote:
> > On Thu, 18 May 2023 at 16:27, Deleu <deleugyn@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 an=
d
> 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 placi=
ng
> > an elephant logo on it, and renaming it "PHPLog=E2=84=A2"?
> >
> > I know that's a bit of a sarcastic response, but it's also a serious on=
e
> -
> > 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 versione=
d
> > 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, bu=
t
> 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 o=
n
> 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 implementati=
on
> of PSR-3 can be depended on to always exists nor a common way all code ca=
n
> get a PSR-3 logger.
>
> So rather than providing Monolog in core, provide a minimal implementatio=
n
> in core =E2=80=94 SimpleLogger maybe? =E2=80=94 as well as the PSR-3 inte=
rfaces and PSR-3
> helper classes[7] plus a few new standard functions to always be availabl=
e
> in PHP. One of those functions =E2=80=94 setLogger() maybe? =E2=80=94 cou=
ld allow users to
> specify the PSR-3 logger they want to use, and many developers could choo=
se
> to use Monolog\Logger.
>
> Another of those functions =E2=80=94 getLogger() maybe? =E2=80=94 could t=
hen be called by
> any PHP code to return an instance of `Psr\Log\LoggerInterface` so that a=
ll
> 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 whic=
h
> 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 u=
se
> 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 woul=
d
> 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 t=
o
> 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 th=
em
> for userland alternatives, ideally with some inclusion of new simple
> standard interfaces and some new functions for could make working with
> instances  =E2=80=94 setSOAPClient()/getSOAPClient() maybe? =E2=80=94 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 the=
m
> 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 Monolo=
g
> > 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 be=
st
> 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 t=
o
> 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 c=
an
> 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 a=
s
> 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-log=
ging.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".

>
>

--000000000000927a4905fc071ccf--