Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120357 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 78300 invoked from network); 19 May 2023 06:26:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 May 2023 06:26:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6423B180384 for ; Thu, 18 May 2023 23:26:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 18 May 2023 23:26:05 -0700 (PDT) Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-561e919d355so25315007b3.0 for ; Thu, 18 May 2023 23:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20221208.gappssmtp.com; s=20221208; t=1684477565; x=1687069565; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ci3DhTlVlPE3UbCtVBRRRn8k/LkdBV1tQdz+jtrhu+M=; b=DYGM/uDjN6fJxnKg77T7f4sISXxtmZXfwxEszA+vnNxqLIAkQRkbNwzlD4CVZeZ8rb VRypub0vn6k3ApLzZ8+inkztFV0Ztvk1nFn+fpIiPFpz0iU0JhxFRVTglNvO+5VZrDRC /YNe4IZNC5G0sPcbNWFbnXTylfmWYdpKzHshvbytozkXYMd2cl1d+4vxtRHFChm0lMZu 3WqS98cwV+pxZUvHnRP+60e3i6hDkG2PZUqJGtzLb+rJC7WcTBtleL6G1350YpJt8mH3 8bnCXAoX1dZL+gsFURPKPa/tBSPaMIs95IbIZV4mnTduIa3dXRFJ5/7L9oO7FRf4qMbO w+kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684477565; x=1687069565; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ci3DhTlVlPE3UbCtVBRRRn8k/LkdBV1tQdz+jtrhu+M=; b=APVz/tdwuBfKdFIpObqcF3rVRDf6e0ordDkgojJnjgHd/JTmNRocUT15nM7IL0wwYt JiJD5G4odAOKFDbfTwBURdHvjDaTRPpVTCTh4NXuS/SeKTg4Opb6ovy3Ja8nwqx0S6Pr rsoNQnIX8iMhOVDIKysML3pxQt01DIh+vQu7qrXBVd5emSVVNyEY5dHYb99slGXiRclq RhHABvWo4jcHzDYPsct1Dqagc5N+bQDnGtD50EeFetdTZTGG58Q5rT29XywsqGjH0iWg 2m2i1Gh2UDmnQgQ0SJWtiR5ol3u/3Tka6FpbggeDxhFwHsvgsiwRc54e4SFenS9aCmRa EjfQ== X-Gm-Message-State: AC+VfDwnLxpwWcJcNEHU3TJ9s1z2m7loTfRruUP48wX0lXtem7OnU4Y+ LtxYU4iCCdosYLhVFxiouJW1pg== X-Google-Smtp-Source: ACHHUZ4QaSbyA8rS0HjSRO5co9oGxrhTLHwa6BuA7HXLhj9oJs73Hunxe7ibVXfYYfVfNnpGiSH61A== X-Received: by 2002:a0d:d5d1:0:b0:54f:bb49:c3a2 with SMTP id x200-20020a0dd5d1000000b0054fbb49c3a2mr913537ywd.28.1684477564866; Thu, 18 May 2023 23:26:04 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id z2-20020a816502000000b00561b76b72d7sm966138ywb.40.2023.05.18.23.26.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2023 23:26:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) In-Reply-To: Date: Fri, 19 May 2023 02:26:03 -0400 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <3DD7832A-5A32-4F21-88F9-FA95B172013D@newclarity.net> References: <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv> To: Rowan Tommins X-Mailer: Apple Mail (2.3696.120.41.1.2) Subject: Re: [PHP-DEV] PHP Package for PHP From: mike@newclarity.net (Mike Schinkel) > 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. >=20 > Then in what sense is it "missing"? What value would be served by = placing > an elephant logo on it, and renaming it "PHPLog=E2=84=A2"? >=20 > 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? >=20 > 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. >=20 > >=20 > 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. =20 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.=20 So rather than providing Monolog in core, provide a minimal = implementation in core =E2=80=94 SimpleLogger maybe? =E2=80=94 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 = =E2=80=94 setLogger() maybe? =E2=80=94 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 =E2=80=94 getLogger() maybe? =E2=80=94 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,=20 2. Flexibility, and=20 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 =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 = 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.=20 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. =20 Said another way, don't think of is as a Core VS. Composer, think of it = as Core AND Composer. =20 -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-logg= ing.md [6] https://www.php-fig.org/psr/psr-3/ [7] https://packagist.org/packages/psr/log=