Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110093 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41929 invoked from network); 8 May 2020 21:34:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 May 2020 21:34:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0F44B1804D3 for ; Fri, 8 May 2020 13:10:27 -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,FROM_EXCESS_BASE64, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS132203 203.205.194.0/23 X-Spam-Virus: No X-Envelope-From: Received: from smtpproxy21.qq.com (smtpbg704.qq.com [203.205.195.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 8 May 2020 13:10:25 -0700 (PDT) X-QQ-mid:Yeas11t1588968614t427t29957 Received: from 4B562073492C4058817F84E016DE3445 (me@jhdxr.com [116.14.113.108]) X-QQ-SSF:00100000000000F0FG1000000000000 To: "'Mike Schinkel'" , "'Dan Ackroyd'" Cc: "'Rowan Tommins'" , "'PHP internals'" , "'Ben Ramsey'" References: <05D65F68-662F-4AE4-8D84-25B1D4279420@newclarity.net> In-Reply-To: <05D65F68-662F-4AE4-8D84-25B1D4279420@newclarity.net> Date: Sat, 9 May 2020 04:10:12 +0800 Message-ID: <004e01d62574$aece7b90$0c6b72b0$@jhdxr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: zh-cn Thread-Index: AQHA5+lLr+j0KwLVD7wGQUF1RbEBjKjJFmgg X-QQ-SENDSIZE: 520 Feedback-ID: Yeas:jhdxr.com:qybgforeign:qybgforeign5 X-QQ-Bgrelay: 1 Subject: RE: [PHP-DEV] A Standard PHAR library included with PHP? From: me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=) This idea has been brought up during the RFC for preloading. I think = it's a good idea because it will make the c part smaller, and reduce the = cost of maintenance. The question is, where should we start with? the = existing functions in C work well, why should we put effect to convert = them back to php. For new functions, it means more workload. The RFC's = author has to convince others that this feature is better to implement = in PHP rather than in C. Regards, CHU Zhaowei -----Original Message----- From: Mike Schinkel =20 Sent: Friday, May 8, 2020 10:03 AM To: Dan Ackroyd Cc: Rowan Tommins ; PHP internals = ; Ben Ramsey Subject: [PHP-DEV] A Standard PHAR library included with PHP? > On May 7, 2020, at 10:33 AM, Dan Ackroyd = wrote: >=20 > On Thu, 7 May 2020 at 10:13, Rowan Tommins = wrote: >>=20 >> Unless we're actively trying to shrink the functionality of PHP's=20 >> core, >=20 > I think we should. >=20 > There are things that were added to core rather than done in userland = because: >=20 > * distributing libraries in userland used to be a lot harder than it = is now. >=20 > * Some stuff needed to be in core to give adequate performance. As=20 > userland PHP has had it's relative performance increased, and also=20 > computers have gotten a little faster since the project began*, that=20 > need has been greatly reduced. One of the primary reasons for many of us =E2=80=94 or at least me = =E2=80=94 to want more things in core is not listed above, and that = reason is: - Standardization As a userland developer I would highly prefer to have the 20% of the = functionality that most everyone needs 80% of the time be provided as = standard functionality by the language rather than delegating the = use-cases to userland resulting in a veritable Tower of Babble in the = userland making too many projects incompatible with each other. If we had more standardization we would have more shared knowledge = across the PHP community. That makes it easier to hire developers, to be = hired and to work on an open-source project as there would be less = duplicated code that people would have learned that each is used very = differently. It would reduce the maintenance burden on userland developers where a = few developers can implement the functionality that the major of = developers no longer have to implement. It would reduce dependencies required. Ironically I was just watching = Github Satellite talk yesterday where they went on and on about how hard = it is to manage and maintain dependencies. And when we use PHP CLI we would generally be able to depend on any = standardized functionality being there. > On May 7, 2020, at 11:28 AM, Ben Ramsey wrote: > In many ways, I agree. In other ways, I see things like = `array_column()` and `str_contains()`[1] as being obvious additions to = the core, since they=E2=80=99re implemented in userland so often.=20 Exactly. The more functionality that is standardized and "just there" = the better. HOWEVER, I do recognize and appreciate at least one of Dan's concerns, = if I interpreted correctly he wants to minimize the maintenance required = for PHP core. Maybe it we all put our heads together we can get both?=20 1.) Minimize maintenance for PHP core, AND=20 2.) Standardize the most commonly-used requirements for functionality? ------------------ One potential option that comes to mind is a standard library of = PHP-written functionality bundled in a PHAR file that would be included = with future implementations of PHP and automatically included by PHP. =20 If we had such as standard PHAR then we could add "standardize" = functionality for all PHP developers and yet reduce the pressure on core = developers to implement and maintain said functionality in PHP C source = code. This would also open up the potential to contribute to PHP to all of = userland, adding many more potential contributors and providing a relief = valve for the C developers maintaining core so there would not be as = much pressure to include things in core and they could easily say "Not = in 'core; do the standard lib instead." Thoughts? -Mike P.S. One argument against a standard library might be that developers = would each want something different for the same use-case so we cannot = standardized. =20 While it is true developers would each have different opinions on what = we should add I think it is also true that =E2=80=94 while developers = will choose wildly different approaches in userland =E2=80=94 once = something is in a standard library most developers just accept it and = move on. And those that don't will still be free to write their own as = they have always been. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, = visit: http://www.php.net/unsub.php =20