Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110078
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <05D65F68-662F-4AE4-8D84-25B1D4279420@newclarity.net>
Date: Thu, 7 May 2020 22:02:50 -0400
Cc: Rowan Tommins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>,
 Ben Ramsey <ben@benramsey.com>
To: Dan Ackroyd <Danack@basereality.com>
Subject: A Standard PHAR library included with PHP?
From: mike@newclarity.net (Mike Schinkel)

> On May 7, 2020, at 10:33 AM, Dan Ackroyd <Danack@basereality.com> =
wrote:
>=20
> On Thu, 7 May 2020 at 10:13, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>>=20
>> Unless we're actively trying to shrink the functionality of PHP's =
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
> 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 =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 <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=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.=