A Standard PHAR library included with PHP?
| From: | Mike Schinkel | Date: | Fri, 08 May 2020 02:02:50 +0000 |
| Subject: | A Standard PHAR library included with PHP? | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-110078@lists.php.net to get a copy of this message | ||
> On May 7, 2020, at 10:33 AM, Dan Ackroyd <Danack@basereality.com> wrote:
>
> On Thu, 7 May 2020 at 10:13, Rowan Tommins <rowan.collins@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 <ben@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.