> On May 7, 2020, at 10:33 AM, Dan Ackroyd <dan...@basereality.com> wrote: > > On Thu, 7 May 2020 at 10:13, Rowan Tommins <rowan.coll...@gmail.com> wrote: >> >> Unless we're actively trying to shrink the functionality of PHP's core, > > I think we should. > > There are things that were added to core rather than done in userland because: > > * distributing libraries in userland used to be a lot harder than it is now. > > * Some stuff needed to be in core to give adequate performance. As > userland PHP has had it's relative performance increased, and also > computers have gotten a little faster since the project began*, that > need has been greatly reduced.
One of the primary reasons for many of us — or at least me — 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 <b...@benramsey.com> 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’re > implemented in userland so often. 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? 1.) Minimize maintenance for PHP core, AND 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. 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. While it is true developers would each have different opinions on what we should add I think it is also true that — while developers will choose wildly different approaches in userland — 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
