Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120338
MIME-Version: 1.0
References: <CADK1yX+aYifoOTwPGnuL3=xDL_NYgFgvZmFAvBfOK333Ohxwrw@mail.gmail.com>
 <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv>
In-Reply-To: <000201d9897f$aa9f9fa0$ffdedee0$@roze.lv>
Date: Thu, 18 May 2023 10:12:16 -0300
Message-ID: <CADK1yXK4U=-POE2h5zu5de1NS0pQE7Rppa6QNxboEeRuOMDYJw@mail.gmail.com>
To: Reinis Rozitis <r@roze.lv>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d428c405fbf78ff0"
Subject: Re: [PHP-DEV] PHP Package for PHP
From: deleugyn@gmail.com (Deleu)

--000000000000d428c405fbf78ff0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 18, 2023 at 8:55=E2=80=AFAM Reinis Rozitis <r@roze.lv> wrote:

> > Which begs the question of a PHP Package for PHP. Some benefits:
> >
> > - Written in PHP, it will allow a much wider pool of contributors than
> the
> scarce pool of C developers contributing to PHP source code.
>
> Aren't this what frameworks are for (Laravel / Yii / Symfony / Zend etc)?
>

I don't believe they are. What they do is try to fill the language gap by
creating competing implementations for common tasks, which then led to the
rise of PSR in an attempt to further address competing abstractions. We
definitely can keep living like this and forget about this matter. My wish
here is just to be able to address a shortcoming PHP has with its standard
library.

My interpretation is that the PHP standard library was born in a completely
different era and was a source of unpleasantness. It is a burden of
maintenance on C developers and it has very little room for mistakes since
once it's embedded in the language a breaking change has a devastating
impact, which led to the current state of: "if it can be done in userland,
it most likely should unless there's extremely strong reason not to". The
bar of improving the standard library is too high and userland does not
have the ability to define one common implementation that can be used
across every project. The only entity that could take a step towards
improving this is the PHP project itself.

Why should PHP take on such a burden?

- It's a greenfield opportunity within the language. I get a vague sense
that it slightly resembles Kotlin for Java or Typescript for Javascript.
Such opportunity could make a huge difference.
- The burden on the current contributors of internals would mostly be about
RFCs and discussions. PHP developers would jump in to provide
implementation and maintenance. If I'm wrong here, then the project can
just die out. I like Dan's description of an RFC here:

> It might be better to think of the RFC process for new features to be
> a decision on "should this feature be in PHP?" rather than a "must
> this feature be in PHP?".

If the PHP community cannot come in together to provide the implementation
of PHP code for an approved RFC, then the PHP community does not need the
benefit of it.
- Plenty of opportunities for mistakes. If a design/implementation turns
out to be wrong, we can leverage namespaces to "fix that" while keeping
backward compatibility for the language at a very low maintenance burden.
- High opportunity for improved user experience. If PHP implementation of
something doesn't work for your particular use case, you can just ignore it
and implement your own. But if done right, we can likely address 80% of use
cases with standard libraries and allow developers to leverage these
implementations across every single PHP project with no extra effort for
the user.
- Improved perception of the language itself. This helps attract newcomers
to the language and reduces the burden of learning some of the PHP quirks
of its standard library.
- Modernization of PHP standard offerings and a home for language
improvements with a lower entry barrier

Perhaps I'm just in a honeymoon trap with the idea which might be blinding
me to its downsides. The only one I truly see is the amount of discussion
and bikeshedding within PHP Internals until implementations land. I don't
know how bad it could get and how it would affect contributors' emotional
energy. But I don't expect it to be bad. I expect it to be PSR on steroids.
And it would be for a limited time. There's only so much we can offer in a
standard library. And then we can enjoy its benefits for many years to come=
.


> Or PEAR?
> Like that particular path_join() request is exactly
> https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Ut=
il.html#methodbuildPath
>
> rr


I have worked with PHP for 14 years now and I know nothing about PEAR. It
either says something about me or about PEAR.

--=20
Marco Deleu

--000000000000d428c405fbf78ff0--