PHP Package for PHP

11 months ago by Deleu — view source

unread

Hi folks!

Reading through https://externals.io/message/120323#120326 and
https://externals.io/message/120323#120332, it reminded me of a few times
I've seen similar debates on internals about "why not do this on userland?"
and the consensus seems to be inclined to only take the maintenance burden
of internals function if there's strong justification for it regardless of
whether there's consensus of being useful or not.

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.
Being official means it inherits the trust PHP already has
Green field development in this day and age often comes with a great set
of automation tests that drastically lowers the maintenance burden
Possibility to standardize a lot of common code that has countless
userland implementations
If we make a mistake of implementing a bad design, the worst thing might
be that we "wasted" a good word in a function or class name. As long as
test coverage is there we can probably just keep it running for many years
with little negative impact other than "yeah, PHP did a bad job at X".

Such a project could benefit from the RFC process already in-place and
voters could take into consideration the lower maintenance burden when
voting for something that they think it's useful.
One relevant downside is that internals might get flooded with RFCs for
filling up some common functionalities for a few years until it dials down
a bit.
It may also lead to re-discussing PHP's entire standard library.

The work to get started seems to be about:

1- Getting an RFC to approve this idea itself
2- Getting a repository to host the PHP package code.
3- CI/CD
4- Release Management
5- Versioning Strategy
6- Package naming convention
7- Distribution strategy (single package vs multiple sub-packages)
8- PHP developers and community contributions

Anything I'm missing? Thoughts?

--
Marco Deleu

11 months ago by Reinis Rozitis — view source

unread

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)?

Or PEAR?
Like that particular path_join() request is exactly https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath

11 months ago by Deleu — view source

unread

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_Util.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.

--
Marco Deleu

11 months ago by Rowan Tommins — view source

unread

Or PEAR?
Like that particular path_join() request is exactly

https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath

I have worked with PHP for 14 years now and I know nothing about PEAR. It
either says something about me or about PEAR.

For many years PEAR was the official package repository for PHP. The client
was shipped with every install of PHP, and still serves as the basis for
PECL, the official distribution for PHP extensions.

From the point of most users, it has been entirely replaced by Composer,
and I think some of the reasons for that are very relevant to this
discussion:

PEAR required a package to be installed globally on a server; Composer
allows (and encourages) it to be local to a particular project
PEAR was a "walled garden" - you had to request permission to publish a
new package, or take over an existing one; Composer is a "bazaar" - anyone
can publish a package to Packagist, and projects can be forked
PEAR tried to be a cohesive ecosystem - it had a unified coding standard,
and a strong policy of package interoperability, aiming for a common "feel"
across all packages; Composer leaves developers to combine packages however
they want

On the one hand, PEAR was a single "baseline" that everyone expected; on
the other hand, packages tended to be slow to adapt to new needs and
fashions, and inflexible to different environments. So instead, people
moved to:

Frameworks; which themselves have mostly adopted a "component-based"
approach interoperating via Composer packages
Non-framework groups like The League of Extraordinary Packages
https://thephpleague.com/
Single packages that have become de facto standards - large projects like
Guzzle and Monolog; and smaller utilities that do one task well, like
Ramsey/UUID

There are two ways I can see a "standard PHP package" working:

As a server-wide install, part of the distributed PHP. That inherits all
the downsides of PEAR, but might be appropriate for a fairly small subset
of really low-level functions.
As a set of Composer packages, managed completely outside the PHP
lifecycle, in which case it's not clear how it would be different from all
the packages that are already out there.

Bottom line, I think there is some merit in having part of the standard
library be written in PHP rather than C, but we'd still want to be very
conservative in what went in there, because most of the downsides of
locking it to the PHP release cycle would still be there, and Composer
seems to be serving the community pretty well for a lot of functionality.

Regards,

Rowan Tommins
[IMSoP]

11 months ago by Deleu — view source

unread

On Thu, May 18, 2023 at 11:27 AM Rowan Tommins rowan.collins@gmail.com
wrote:

Or PEAR?
Like that particular path_join() request is exactly

https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath

I have worked with PHP for 14 years now and I know nothing about PEAR. It
either says something about me or about PEAR.

For many years PEAR was the official package repository for PHP. The client
was shipped with every install of PHP, and still serves as the basis for
PECL, the official distribution for PHP extensions.

From the point of most users, it has been entirely replaced by Composer,
and I think some of the reasons for that are very relevant to this
discussion:

PEAR required a package to be installed globally on a server; Composer
allows (and encourages) it to be local to a particular project

PEAR was a "walled garden" - you had to request permission to publish a
new package, or take over an existing one; Composer is a "bazaar" - anyone
can publish a package to Packagist, and projects can be forked

PEAR tried to be a cohesive ecosystem - it had a unified coding standard,
and a strong policy of package interoperability, aiming for a common "feel"
across all packages; Composer leaves developers to combine packages however
they want

On the one hand, PEAR was a single "baseline" that everyone expected; on
the other hand, packages tended to be slow to adapt to new needs and
fashions, and inflexible to different environments. So instead, people
moved to:

Frameworks; which themselves have mostly adopted a "component-based"
approach interoperating via Composer packages

Non-framework groups like The League of Extraordinary Packages
https://thephpleague.com/

Single packages that have become de facto standards - large projects like
Guzzle and Monolog; and smaller utilities that do one task well, like
Ramsey/UUID

Thanks for the history lesson, this is super useful information, indeed.
Monolog is a great example of what PHP is missing - a single library for a
purpose. I have never worked with any other library besides Monolog and I
never worked on any project which didn't have it installed. Perhaps my
bubble might be a limiting factor here, but I get a feeling that Monolog is
considered to be The Logging PHP Library.

Guzzle is a near 2nd, but not quite there, especially after Symfony built
their own HTTP Client and further drove the community split. Laravel has an
amazing Arr class that wraps most of PHP's array_* standard library and I
love it and find it amazing, but it's a niche community within PHP.
Newcomers might get exposed to community debates[1] that end up driving
them away from taking advantage of a better array_* suite. Laravel's Arr
class also didn't get scrutinized by PHP RFC so there's no way to know
whether it's all good, some good or all bad.

There are two ways I can see a "standard PHP package" working:

As a server-wide install, part of the distributed PHP. That inherits all
the downsides of PEAR, but might be appropriate for a fairly small subset
of really low-level functions.

As a set of Composer packages, managed completely outside the PHP
lifecycle, in which case it's not clear how it would be different from all
the packages that are already out there.

Bottom line, I think there is some merit in having part of the standard
library be written in PHP rather than C, but we'd still want to be very
conservative in what went in there, because most of the downsides of
locking it to the PHP release cycle would still be there, and Composer
seems to be serving the community pretty well for a lot of functionality.

Regards,

Rowan Tommins
[IMSoP]

I also see both options for this to work, but honestly I have no strong
feelings either way. For me it's pretty clear that a set of Composer
packages offering standard libraries under the PHP namespace and limited to
what gets approved by RFCs would be a lot different from all the packages
that are all there because it takes away all the time and energy
collectively spent in evaluating options and their reputations. We can get
started with what PHP offers by default and delay the evaluation process
until the PHP standard library no longer supports the use case. It's the
standard option and is covered by PHP's reputation. If your use case is not
standard, you might reach for a community-provided library that enhances
the standard library needs or build your own instead of always having to
use a community-provided library or build your own.

I also like the option of bundling it together with PHP, but that would
take some effort on PHP's Core Developers and I'd rather take the benefits
of having a PHP Standard Composer Package than to risk not having it
because it increases Core Developers' maintenance burden. The nice thing
about it is that if the idea works out great, a new RFC can be written to
bring the package into core and have that decision voted individually on
its own merits.

Finally, one awesome aspect I also see is that when time comes to
deprecate, abandon or "fix" design flaws in the PHP Standard Library,
regardless of whether it's bundled or a composer package, it can always be
ejected into a composer package. If 20 years from now there's a major
"legacy" project with a heavy dependency on something that PHP decides to
deprecate, they can just fork the package and embed it with their
application. One can argue that maybe we can do that today as long as we
write a custom PHP extension, but then comes the burden of PHP developers
having to know how to develop C and use PHP's extension system to try and
bring back functionality that was dropped from the language.

--
Marco Deleu

11 months ago by Rowan Tommins — view source

unread

Monolog is a great example of what PHP is missing - a single library for a

purpose. I have never worked with any other library besides Monolog and I
never worked on any project which didn't have it installed. Perhaps my
bubble might be a limiting factor here, but I get a feeling that Monolog is
considered to be The Logging PHP Library.

Then in what sense is it "missing"? What value would be served by placing
an elephant logo on it, and renaming it "PHPLog™"?

I know that's a bit of a sarcastic response, but it's also a serious one -
what would we define as the aims of a replacement for Monolog, which aren't
currently being served?

We could guarantee it was installed with every version of PHP, but only by
severely restricting its release cycle, so that every PHP version had
exactly one version of Monolog. If it remains an independently versioned
Composer package, I can't think of much that would change.

Laravel's Arr class also didn't get scrutinized by PHP RFC so there's no
way to know whether it's all good, some good or all bad.

I don't think PHP's decision-making process can be held up as a shining
example of good governance, in contrast to everyone else's anarchy. I don't
know much about Laravel's governance, but I am quite sure every change is
discussed and iterated on before release. In fact, they probably have a
whole bunch of standards and processes that PHP is lacking, and would have
to invent to make any new library a success.

... it takes away all the time and energy collectively spent in evaluating
options and their reputations.

I don't think that's really true; reputations have to be earned, and
maintained.

Taking the logging example, imagine we decided that, to paraphrase Dr
Strangelove, "We can't allow a logging gap!" So we hack together a logging
package that's worse in every way than Monolog, but call it "official".
Half the community will ignore it and carry on using Monolog; the other
half won't realise that a better alternative exists, and be worse off from
today.

I actually wonder if some things in core should be removed to encourage
userland replacements - ext/soap, for instance, and some of the data
structures in ext/spl.

IMHO, the things that would benefit from being written in PHP then bundled
are things that are so low-level that it's hard to get them wrong; the
building blocks that the community will use to build things like Monolog
and Guzzle.

Regards,

Rowan Tommins
[IMSoP]

11 months ago by Larry Garfield — view source

unread

I actually wonder if some things in core should be removed to encourage
userland replacements - ext/soap, for instance, and some of the data
structures in ext/spl.

IMHO, the things that would benefit from being written in PHP then bundled
are things that are so low-level that it's hard to get them wrong; the
building blocks that the community will use to build things like Monolog
and Guzzle.

Another related prior: There's been on and off discussion for some time about moving stdlib C functions into PHP, and relying on preloading and JIT to make them fast. So far that hasn't happened, mainly because when someone has tried it out (mainly Nikita), it turned out to not be as fast as the existing C versions.

I think there's a couple of different categories of library-esque code that need to be considered:

Low-level tooling that pretty much has to be in C to work correctly. This is pretty well covered already. Examples here are things like ext/curl, ext/pdo, streams, reflection, etc.
Application level tooling that almost every app needs. Logging is the obvious example here.
Base functionality that is notably faster in C than PHP. Here I include things like array_map(), array_reduce(), strlen(), etc. Much of those could be done in user-space, but there's an appreciable performance benefit to them being native in C. The new Random extension, too, could have been implemented in user-space, but would have been vastly slower.
Base functionality that is not notably faster in C, but is still considered "basic table stakes" for the type system. iterator_to_array(), for instance, could absolutely be implemented in user space, and probably wouldn't be any slower, but it's such a basic part of working with iterables that it would be an incomplete product to not have it. I would put str_contains() in the same category; it offers no real benefit other than 100% guaranteed presence, but that's enough in some cases.
Functionality that is often used, but not always, and gets no significant benefit from being in C.

Those boundaries are a bit squishy, of course, with lots of edge cases.

Personally, I don't think category 2 should be in the stdlib. That might have made sense 20 years ago, but between Composer and PHP-FIG, I don't think the argument is that compelling. Similarly, category 5 is best left to user-space. Category 1, obviously, should at least be PECL, but often in php-src standard.

The tricky questions relate to what qualifies as "base functionality" and "basic table stakes", as well as how much of a performance improvement is necessary to justify inclusion (categories 3 and 4). There's also questions of historical precedent, but PHP's historical precedent is a total mess in most cases so that's not as strong an argument. :-)

As an example, ramsey/uuid is the standard library for UUID generation. It seems to work pretty well in user-space. However, one could argue that it's "common enough" that it should be universally available. Maybe. A C implementation would undoubtedly be faster than in PHP but... by how much? If it were 10% faster, would that justify inclusion in core? How about 30% faster? 3x faster than user-space?

Where is the cutoff for "enough performance different" and "common enough usage"?

We have no consensus on that right now, nor do we even ask the question so directly in most cases. We should be, though, lest we just fall back on personal emotional responses.

--Larry Garfield

11 months ago by Ilija Tovilo — view source

unread

Hi Marco

Monolog is a great example of what PHP is missing - a single library for a

purpose. I have never worked with any other library besides Monolog and I
never worked on any project which didn't have it installed. Perhaps my
bubble might be a limiting factor here, but I get a feeling that Monolog is
considered to be The Logging PHP Library.

Then in what sense is it "missing"? What value would be served by placing
an elephant logo on it, and renaming it "PHPLog™"?

I know that's a bit of a sarcastic response, but it's also a serious one -
what would we define as the aims of a replacement for Monolog, which aren't
currently being served?

We could guarantee it was installed with every version of PHP, but only by
severely restricting its release cycle, so that every PHP version had
exactly one version of Monolog. If it remains an independently versioned
Composer package, I can't think of much that would change.

I fully agree with Rowan. These packages have had many years to get to
where they are, and are maintained by capable people. Putting an
official stamp on them doesn't make them qualitatively better.

I could see an argument being made for bundling them with PHP so that
Composer is not required, but that does not seem smart for large
libraries that need the freedom to evolve. I'm absolutely in favor for
a more complete standard library in terms of basic operations, e.g.
better iterator support.

Laravel's Arr class also didn't get scrutinized by PHP RFC so there's no
way to know whether it's all good, some good or all bad.

I don't think PHP's decision-making process can be held up as a shining
example of good governance, in contrast to everyone else's anarchy. I don't
know much about Laravel's governance, but I am quite sure every change is
discussed and iterated on before release. In fact, they probably have a
whole bunch of standards and processes that PHP is lacking, and would have
to invent to make any new library a success.

Moreover, I believe the main barrier for adding new functions to PHPs
standard library is not C but the RFC process itself. "Trial and
error" is much easier than making 50+ people agree on the correct
solution on the first try.

I suppose something we could try is an "official but experimental"
Composer package for testing new classes/functions for the standard
library before stabilizing them and rewriting them in C. Maybe this
could prevent some of the bike-shedding.

Ilija

11 months ago by Deleu — view source

unread

On Thu, May 18, 2023 at 2:35 PM Rowan Tommins rowan.collins@gmail.com
wrote:

Monolog is a great example of what PHP is missing - a single library for a

purpose. I have never worked with any other library besides Monolog and I
never worked on any project which didn't have it installed. Perhaps my
bubble might be a limiting factor here, but I get a feeling that Monolog
is
considered to be The Logging PHP Library.

Then in what sense is it "missing"? What value would be served by placing
an elephant logo on it, and renaming it "PHPLog™"?

I meant exactly the opposite. Monolog is an example of what PHP (is missing
=== doesn't have enough of). There's hardly any reason to re-release it
under the PHP umbrella. Monolog already won the log battle. I can't say the
same for virtually anything else, to be honest. Some folks might say that
Guzzle won the HTTP battle, I just disagree and think we could have
something better by default, such as Python's request Library, but I can
also see such controversy being lost and leaving PHP without an HTTP Client
built-in. That would be a matter for each individual RFC.

Laravel's Arr class also didn't get scrutinized by PHP RFC so there's
no
way to know whether it's all good, some good or all bad.

I don't think PHP's decision-making process can be held up as a shining
example of good governance, in contrast to everyone else's anarchy. I don't
know much about Laravel's governance, but I am quite sure every change is
discussed and iterated on before release. In fact, they probably have a
whole bunch of standards and processes that PHP is lacking, and would have
to invent to make any new library a success.

I didn't mean anything about PHP's governance, to be honest. I am, however,
very aware of the community battle around frameworks. I like Laravel's Arr
class, but there are PHP developers that hate all things Laravel. What PHP
governance brings here is that if it can't be agreed on, it won't be
included. So perhaps an RFC discussing PHP's Array functions could end up
taking some of Laravel's implementations or none. My point here was mostly
about the fact that a PHP Standard Package addition going through PHP RFC
has a lower entry barrier compared to built in C, but a higher entry level
than anybody in the PHP community creating a package they personally like
for themselves. The combined experience of internals participants is at
least pretty good to bring a lot of perspectives.

--
Marco Deleu

11 months ago by Rowan Tommins — view source

unread

I meant exactly the opposite. Monolog is an example of what PHP (is missing
=== doesn't have enough of). There's hardly any reason to re-release it
under the PHP umbrella. Monolog already won the log battle. I can't say the
same for virtually anything else, to be honest. Some folks might say that
Guzzle won the HTTP battle, I just disagree and think we could have
something better by default

Let's look at HTTP clients then.

PHP is certainly lacking a good one built in. Using streams with allow_url_fopen is serviceable for fetching a page, but not much else; the curl functions are ... embarrassing.

On the other hand, Guzzle has gone through 7 major version bumps in 12 years, presumably believing that each improvement justified the disruption to users. And even then, as you point out, Symfony decided to write their own HttpClient component. Clearly, they didn't do that because they didn't know Guzzle existed; presumably, they thought it still wasn't good enough.

An extension or library fully bundled with PHP would have no hope of competing with that. A major version could only be made every 5 years, and even then breaking changes have to be minimised, so we would really have one chance to somehow improve on what others have spent years refining.

On the other hand, a clean API with a much smaller feature set, which could be used on its own for simple use cases, and be the low level implementation for Guzzle, Symfony HttpClient, etc, would be extremely useful. In other words, an overhaul of the curl functions to give the same flexibility, but an API that feels more native to PHP, rather than a thin wrapper around the C functions of libcurl.

Whether it would make sense to do that in PHP, I'm not so sure. It would mean that any fundamentally new feature would need implementing twice: once in C, in the existing clunky API, then again in PHP, to wrap it into a different style. On the other hand, it would make polyfilling the new API trivial, and have a wider pool of contributors who could work on it - as long as they didn't hit a limitation that needed to be fixed in the C layer.

Regards,

Rowan Tommins
[IMSoP]

11 months ago by Deleu — view source

unread

On Thu, May 18, 2023 at 6:56 PM Rowan Tommins rowan.collins@gmail.com
wrote:

I meant exactly the opposite. Monolog is an example of what PHP (is
missing
=== doesn't have enough of). There's hardly any reason to re-release it
under the PHP umbrella. Monolog already won the log battle. I can't say
the
same for virtually anything else, to be honest. Some folks might say that
Guzzle won the HTTP battle, I just disagree and think we could have
something better by default

Let's look at HTTP clients then.

PHP is certainly lacking a good one built in. Using streams with
allow_url_fopen is serviceable for fetching a page, but not much else; the
curl functions are ... embarrassing.

[..]

On the other hand, a clean API with a much smaller feature set, which could

be used on its own for simple use cases, and be the low level
implementation for Guzzle, Symfony HttpClient, etc, would be extremely
useful. In other words, an overhaul of the curl functions to give the same
flexibility, but an API that feels more native to PHP, rather than a thin
wrapper around the C functions of libcurl.

Let me start from here where we agree on. We start by designing a new PHP
package to wrap cURL. Bear in mind for a minute that I started this thread
with the intention of lowering the barrier of getting RFC approved and the
code being maintained by PHP developers. After some good amount of
bikeshedding we approve the first PHP package. It is fully covered by
automation tests so that future maintenance is relatively easy. It gets
released under the namespace Php\8.4\Curl. I'm going to be greedy here and
assume we even get it bundled inside PHP. Before PHP 8.4 gets released we
also work on Php\8.4\Strings package.

For the sake of argument let's pretend that within 1 month of PHP 8.4
release we discover that the Curl package was actually really bad and we
decide to rework it. A new RFC is approved and we bundle a new design under
Php\8.5\Curl. Meanwhile Strings was a success and no new version is
warranted. So Php\8.5\Strings does not need to exist.

Now both new designs are still great and Php\8.6\Curl and Php\8.6\Strings
do not need to exist either. Perhaps someone raises an RFC so that PHP 8.7
will unbundle/eject Php\8.4\Curl and keep only Php\8.5\Curl inside PHP.
It's a breaking change, but one that just means we now move the code to
being Composer-only instead of bundled inside PHP. It's a "deprecated"
package that can just exist on GitHub for backwards compatibility. A few
more years go by and another RFC comes in to abandon Php\8.4\Curl from the
PHP Group.

This whole story, from a user standpoint, screams stability. If a project
starts using Php\8.4\Curl and gets so deep into it that it's too expensive
for them to upgrade, they can just keep using it without upgrading to the
8.5 counterpart while still upgrading their PHP binary. If it gets
unbundled, they can just composer require it. If years go by and the
package gets abandoned, they can still fork it and pretty much no code
change would be necessary.

With namespaces, PHP Packages get to do "Editions" without all of the
complexity of doing editions at the engine level. Written in PHP, it can
easily get ejected out of the PHP binary and still be
"backward-compatible".

PHP seems to be at a corner where it's best not to do anything than to make
another mistake. A mistake made in the design of the language takes decades
to undo. I believe we can improve the language's basic functionality this
way and slowly grow into wrapping most features needed by the majority of
web applications. We could start with just wrapping libcurl in a nicer API
and if it works out great we could do more until one day we end up even
providing a slim HTTP Client. The PHP community as a whole (regardless of
which framework camp you are in) as well as newcomers could only benefit
from it.

--
Marco Deleu

11 months ago by Gunnard engebreth — view source

unread

On Thu, May 18, 2023 at 6:56 PM Rowan Tommins rowan.collins@gmail.com
wrote:

I meant exactly the opposite. Monolog is an example of what PHP (is
missing
=== doesn't have enough of). There's hardly any reason to re-release it
under the PHP umbrella. Monolog already won the log battle. I can't say
the
same for virtually anything else, to be honest. Some folks might say that
Guzzle won the HTTP battle, I just disagree and think we could have
something better by default

Let's look at HTTP clients then.

PHP is certainly lacking a good one built in. Using streams with
allow_url_fopen is serviceable for fetching a page, but not much else; the
curl functions are ... embarrassing.

[..]

On the other hand, a clean API with a much smaller feature set, which could

be used on its own for simple use cases, and be the low level
implementation for Guzzle, Symfony HttpClient, etc, would be extremely
useful. In other words, an overhaul of the curl functions to give the same
flexibility, but an API that feels more native to PHP, rather than a thin
wrapper around the C functions of libcurl.

Let me start from here where we agree on. We start by designing a new PHP
package to wrap cURL. Bear in mind for a minute that I started this thread
with the intention of lowering the barrier of getting RFC approved and the
code being maintained by PHP developers. After some good amount of
bikeshedding we approve the first PHP package. It is fully covered by
automation tests so that future maintenance is relatively easy. It gets
released under the namespace Php\8.4\Curl. I'm going to be greedy here and
assume we even get it bundled inside PHP. Before PHP 8.4 gets released we
also work on Php\8.4\Strings package.

For the sake of argument let's pretend that within 1 month of PHP 8.4
release we discover that the Curl package was actually really bad and we
decide to rework it. A new RFC is approved and we bundle a new design under
Php\8.5\Curl. Meanwhile Strings was a success and no new version is
warranted. So Php\8.5\Strings does not need to exist.

Now both new designs are still great and Php\8.6\Curl and Php\8.6\Strings
do not need to exist either. Perhaps someone raises an RFC so that PHP 8.7
will unbundle/eject Php\8.4\Curl and keep only Php\8.5\Curl inside PHP.
It's a breaking change, but one that just means we now move the code to
being Composer-only instead of bundled inside PHP. It's a "deprecated"
package that can just exist on GitHub for backwards compatibility. A few
more years go by and another RFC comes in to abandon Php\8.4\Curl from the
PHP Group.

This whole story, from a user standpoint, screams stability. If a project
starts using Php\8.4\Curl and gets so deep into it that it's too expensive
for them to upgrade, they can just keep using it without upgrading to the
8.5 counterpart while still upgrading their PHP binary. If it gets
unbundled, they can just composer require it. If years go by and the
package gets abandoned, they can still fork it and pretty much no code
change would be necessary.

With namespaces, PHP Packages get to do "Editions" without all of the
complexity of doing editions at the engine level. Written in PHP, it can
easily get ejected out of the PHP binary and still be
"backward-compatible".

PHP seems to be at a corner where it's best not to do anything than to make
another mistake. A mistake made in the design of the language takes decades
to undo. I believe we can improve the language's basic functionality this
way and slowly grow into wrapping most features needed by the majority of
web applications. We could start with just wrapping libcurl in a nicer API
and if it works out great we could do more until one day we end up even
providing a slim HTTP Client. The PHP community as a whole (regardless of
which framework camp you are in) as well as newcomers could only benefit
from it.

PHP seems to be at a corner where it's best not to do anything than to make
another mistake. A mistake made in the design of the language takes decades
to undo.

I think this is a bold statement about the state of PHP and should have the backing to hold it up.

we could start with just wrapping libcurl in a nicer API
and if it works out great we could do more until one day we end up even
providing a slim HTTP Client.

php and curl are two seperate "things" entaties if you will, libcurl works very well on its own.
I hear you in your want to have a united community of frameworks but as of now, php is (and correct me if I am wrong in projecting this) is a community that helps to provide ways to use PHP in usefull environments.

"
PHP seems to be at a corner where it's best not to do anything than to make
another mistake.
"
I think you are more on the money than you are not... but this does not mean that PHP is in anyone's pocket

11 months ago by Mike Schinkel — view source

unread

Monolog is a great example of what PHP is missing - a single library for a
purpose. I have never worked with any other library besides Monolog and I
never worked on any project which didn't have it installed. Perhaps my
bubble might be a limiting factor here, but I get a feeling that Monolog is
considered to be The Logging PHP Library.

Then in what sense is it "missing"? What value would be served by placing
an elephant logo on it, and renaming it "PHPLog™"?

I know that's a bit of a sarcastic response, but it's also a serious one -
what would we define as the aims of a replacement for Monolog, which aren't
currently being served?

We could guarantee it was installed with every version of PHP, but only by
severely restricting its release cycle, so that every PHP version had
exactly one version of Monolog. If it remains an independently versioned
Composer package, I can't think of much that would change.
<snip>
Taking the logging example, imagine we decided that, to paraphrase Dr
Strangelove, "We can't allow a logging gap!" So we hack together a logging
package that's worse in every way than Monolog, but call it "official".
Half the community will ignore it and carry on using Monolog; the other
half won't realise that a better alternative exists, and be worse off from
Today.

That statement only envisions inclusion of OR replacement for Monolog, but not adding support to PHP core that would offer a standard way to USE Monolog. Let me explain.

And it is helpful logging was mentioned as an example because we can look to other languages to see what they have done, and Go just recently did exactly that.

Go proposed[1] then added[2] a Structured Logging package to the Go standard library even though there are many logging packages already available for Go and in wide use[3], just as PHP has several logging packages[4]. Their design doc[5] explains their rationale.

Basically they wanted to include a common set of code that will operate on a new standard interface. For PHP logging there is already a standard interface; PSR-3[6], but what PHP does not have is an actual implementation of PSR-3 can be depended on to always exists nor a common way all code can get a PSR-3 logger.

So rather than providing Monolog in core, provide a minimal implementation in core — SimpleLogger maybe? — as well as the PSR-3 interfaces and PSR-3 helper classes[7] plus a few new standard functions to always be available in PHP. One of those functions — setLogger() maybe? — could allow users to specify the PSR-3 logger they want to use, and many developers could choose to use Monolog\Logger.

Another of those functions — getLogger() maybe? — could then be called by any PHP code to return an instance of Psr\Log\LoggerInterface so that all code can depend a logger existing. If no PHP code had previously called setLogger() then getLogger() would first instantiate a new SimpleLogger, pass it to setLogger(), and then return that object for the caller to use.

So what is "missing" is not the logging library per se, but instead the plumbing that would make it possible for code from multiple different authors working independently to all be able to write code that logs which will still be interoperable, know that a logger will be guaranteed to be available (it could even be a null logger), and also have the option to use Monolog, some other PSR-3 library, or write their own new special-purpose logger; whatever their choice.

Said another way, the value gained by placing an elephant logo on it would be:

Interoperability,
Flexibility, and
A guarantee of existence when called.

I actually wonder if some things in core should be removed to encourage
userland replacements - ext/soap, for instance, and some of the data
structures in ext/spl.

Having a PHP core standard library could allow for some of those things to be reimplemented in PHP but still included in PHP core. That would reduce the need to maintain them in C, and would be a way to slowly deprecate them for userland alternatives, ideally with some inclusion of new simple standard interfaces and some new functions for could make working with instances — setSOAPClient()/getSOAPClient() maybe? — to allow people to use the built-in ones or to replace with their own.

ext/spl could be moved to a PHP core standard library assuming doing so was performant enough and/or new features were added to core to allow them to be implemented in a performant manner that did not kneecap performant-sensitive code that use them.

IMHO, the things that would benefit from being written in PHP then bundled
are things that are so low-level that it's hard to get them wrong; the
building blocks that the community will use to build things like Monolog
and Guzzle.

Imagine all the PSR interfaces as well as default simple implementations for each and where applicable a set of functions to set and get those instances to be included in a PHP standard core library.

If those were implemented in a PHP standard core library that there might even be motivation to develop new PSR interfaces derived from existing best practices in the wild, as right now that useful effort seems to have stalled. For example, I could see an interface and default implementation for working with ChatGPT like AI being something that people might want to look into in the near future.

Again, the value IMO for having a PHP core standard library is not necessarily about being able to add functionality, but to add code that can enable code from multiple developers to work independently yet inter-operably with new or existing functionality out in the wild.

Said another way, don't think of is as a Core VS. Composer, think of it as Core AND Composer.

-Mike

P.S. I know this thread was motivated by desire to allow PHP functions to be added to core, and I won't argue that would not be a nice-to-have option, but I think the real value would be to include interfaces, simple implementations and related functions that could enable and encourage interoperability across PHP code written by different authors independently. And having that latter would certainly not preclude the former, from time to time.

[1] https://github.com/golang/go/issues/56345
[2] https://pkg.go.dev/golang.org/x/exp/slog
[3] https://blog.logrocket.com/5-structured-logging-packages-for-go/
[4] https://www.loggly.com/ultimate-guide/php-logging-libraries/
[5] https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md
[6] https://www.php-fig.org/psr/psr-3/
[7] https://packagist.org/packages/psr/log

11 months ago by Arvids Godjuks — view source

unread

On May 18, 2023, at 1:34 PM, Rowan Tommins rowan.collins@gmail.com
wrote:

Monolog is a great example of what PHP is missing - a single library
for a
purpose. I have never worked with any other library besides Monolog and
I
never worked on any project which didn't have it installed. Perhaps my
bubble might be a limiting factor here, but I get a feeling that
Monolog is
considered to be The Logging PHP Library.

Then in what sense is it "missing"? What value would be served by placing
an elephant logo on it, and renaming it "PHPLog™"?

I know that's a bit of a sarcastic response, but it's also a serious one

what would we define as the aims of a replacement for Monolog, which
aren't
currently being served?

We could guarantee it was installed with every version of PHP, but only
by
severely restricting its release cycle, so that every PHP version had
exactly one version of Monolog. If it remains an independently versioned
Composer package, I can't think of much that would change.
<snip>
Taking the logging example, imagine we decided that, to paraphrase Dr
Strangelove, "We can't allow a logging gap!" So we hack together a
logging
package that's worse in every way than Monolog, but call it "official".
Half the community will ignore it and carry on using Monolog; the other
half won't realise that a better alternative exists, and be worse off
from
Today.

That statement only envisions inclusion of OR replacement for Monolog, but
not adding support to PHP core that would offer a standard way to USE
Monolog. Let me explain.

And it is helpful logging was mentioned as an example because we can look
to other languages to see what they have done, and Go just recently did
exactly that.

Go proposed[1] then added[2] a Structured Logging package to the Go
standard library even though there are many logging packages already
available for Go and in wide use[3], just as PHP has several logging
packages[4]. Their design doc[5] explains their rationale.

Basically they wanted to include a common set of code that will operate on
a new standard interface. For PHP logging there is already a standard
interface; PSR-3[6], but what PHP does not have is an actual implementation
of PSR-3 can be depended on to always exists nor a common way all code can
get a PSR-3 logger.

So rather than providing Monolog in core, provide a minimal implementation
in core — SimpleLogger maybe? — as well as the PSR-3 interfaces and PSR-3
helper classes[7] plus a few new standard functions to always be available
in PHP. One of those functions — setLogger() maybe? — could allow users to
specify the PSR-3 logger they want to use, and many developers could choose
to use Monolog\Logger.

Another of those functions — getLogger() maybe? — could then be called by
any PHP code to return an instance of Psr\Log\LoggerInterface so that all
code can depend a logger existing. If no PHP code had previously called
setLogger() then getLogger() would first instantiate a new SimpleLogger,
pass it to setLogger(), and then return that object for the caller to use.

So what is "missing" is not the logging library per se, but instead the
plumbing that would make it possible for code from multiple different
authors working independently to all be able to write code that logs which
will still be interoperable, know that a logger will be guaranteed to be
available (it could even be a null logger), and also have the option to use
Monolog, some other PSR-3 library, or write their own new special-purpose
logger; whatever their choice.

Said another way, the value gained by placing an elephant logo on it would
be:

Interoperability,

Flexibility, and

A guarantee of existence when called.

I actually wonder if some things in core should be removed to encourage
userland replacements - ext/soap, for instance, and some of the data
structures in ext/spl.

Having a PHP core standard library could allow for some of those things to
be reimplemented in PHP but still included in PHP core. That would reduce
the need to maintain them in C, and would be a way to slowly deprecate them
for userland alternatives, ideally with some inclusion of new simple
standard interfaces and some new functions for could make working with
instances — setSOAPClient()/getSOAPClient() maybe? — to allow people to
use the built-in ones or to replace with their own.

ext/spl could be moved to a PHP core standard library assuming doing so
was performant enough and/or new features were added to core to allow them
to be implemented in a performant manner that did not kneecap
performant-sensitive code that use them.

IMHO, the things that would benefit from being written in PHP then
bundled
are things that are so low-level that it's hard to get them wrong; the
building blocks that the community will use to build things like Monolog
and Guzzle.

Imagine all the PSR interfaces as well as default simple implementations
for each and where applicable a set of functions to set and get those
instances to be included in a PHP standard core library.

If those were implemented in a PHP standard core library that there might
even be motivation to develop new PSR interfaces derived from existing best
practices in the wild, as right now that useful effort seems to have
stalled. For example, I could see an interface and default implementation
for working with ChatGPT like AI being something that people might want to
look into in the near future.

Again, the value IMO for having a PHP core standard library is not
necessarily about being able to add functionality, but to add code that can
enable code from multiple developers to work independently yet
inter-operably with new or existing functionality out in the wild.

Said another way, don't think of is as a Core VS. Composer, think of it as
Core AND Composer.

-Mike

P.S. I know this thread was motivated by desire to allow PHP functions to
be added to core, and I won't argue that would not be a nice-to-have
option, but I think the real value would be to include interfaces, simple
implementations and related functions that could enable and encourage
interoperability across PHP code written by different authors
independently. And having that latter would certainly not preclude the
former, from time to time.

[1] https://github.com/golang/go/issues/56345
[2] https://pkg.go.dev/golang.org/x/exp/slog
[3] https://blog.logrocket.com/5-structured-logging-packages-for-go/
[4] https://www.loggly.com/ultimate-guide/php-logging-libraries/
[5]
https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md
[6] https://www.php-fig.org/psr/psr-3/
[7] https://packagist.org/packages/psr/log

To unsubscribe, visit: https://www.php.net/unsub.php

I think this whole thread can be summarized into a single statement:

"Let's integrate PSR standards into PHP core and ship those interfaces as
part of the language".

10 months ago by Rowan Tommins — view source

unread

On Fri, 19 May 2023 at 08:45, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I think this whole thread can be summarized into a single statement:

"Let's integrate PSR standards into PHP core and ship those interfaces as
part of the language"

That's one of the angles that's come up, but there are also some other
interesting ideas, a lot of which are actually independent of each other,
including:

implementing simple core functions in PHP rather than C
using namespaces as a form of versioning
having a default set of includes which can be over-ridden by user code

The one recurring theme I would pick up on though is a general optimism
about how much we could add, and get right. Call me cynical, but I don't
share that optimism. The main reason a lot of the things being discussed
don't already exist is not that PHP only accepts contributions in C, or
that Composer packages aren't installed by default; it's that nobody has
worked out the One True Design.

Moving the discussion to this list rather than PHP-FIG, or PHPLeague, or
Symfony, etc, won't make that design process any easier. If anything, it
will make it harder - the stakes are higher, and the abilities for rework
and forking far more restricted.

Regards,

Rowan Tommins
[IMSoP]

10 months ago by Larry Garfield — view source

unread

On Fri, 19 May 2023 at 08:45, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I think this whole thread can be summarized into a single statement:

"Let's integrate PSR standards into PHP core and ship those interfaces as
part of the language"

That's one of the angles that's come up, but there are also some other
interesting ideas, a lot of which are actually independent of each other,
including:

implementing simple core functions in PHP rather than C

using namespaces as a form of versioning

having a default set of includes which can be over-ridden by user code

The one recurring theme I would pick up on though is a general optimism
about how much we could add, and get right. Call me cynical, but I don't
share that optimism. The main reason a lot of the things being discussed
don't already exist is not that PHP only accepts contributions in C, or
that Composer packages aren't installed by default; it's that nobody has
worked out the One True Design.

Moving the discussion to this list rather than PHP-FIG, or PHPLeague, or
Symfony, etc, won't make that design process any easier. If anything, it
will make it harder - the stakes are higher, and the abilities for rework
and forking far more restricted.

I would also note that a One True Design rarely comes from a committee-of-the-whole-who-is-mostly-disengaged. Symfony has a very clear core leadership that can Decide Things(tm), which helps to keep the design consistent. The same is true of Monolog, Guzzle, Ramsey/UUID, PHPUnit, and the rest of the "de facto standard library." In the case of FIG, we moved away from the "everyone in one big pile" approach many years ago toward dedicated, explicitly-named, explicitly-empowered working groups, and it has been a much more successful approach.

(As a side note, nominations are open now for the FIG Core Committee and secretary positions, if anyone is interested.)

Internals, in its current form, is structurally incapable of the design decisions that would need to be made for a "default versions of PSRs bundled with the language" initiative, regardless of whether it's written in C or PHP.

--Larry Garfield

10 months ago by Robert Landers — view source

unread

I'd also like to add that I like the 'hands-off' approach that PHP has
taken in the past. I'm not a fan of some of the PSRs. I literally had
someone tell me a few months ago that I would never be a 'real
programmer' because I used tabs instead of spaces which is against the
PSR-12 spec (which is my only deviation from the spec, and why is that
even in the spec in the first place? :sigh:). Luckily for me, I guess,
I think I'm 'real programmer' ... even though it still feels like a
hobby (even 20 years later), but people pay me a bunch of money to do
it and people seem to like my work.

IMHO, the downside of PHP enshrining things like PSRs is that it
discourages people from 'breaking the rules', which is where true
innovation comes from (IMHO). Symfony wouldn't be as fast without
goto, Laravel without it's facade thing, and WordPress without its
hooks. If you look at other languages like Python, Go, C#, etc, that
have come up with The-One-True-Way, you'll pick up codebases and it
just looks like any other codebase. It takes all the fun out it.
Nobody wants to live in a house that looks like every other house.
Organizations should be able to talk about variable alignment over a
coffee if it drives them nuts, and not get shot down because of some
spec a committee wrote ten years ago.

My 2 cents... fwiw.

10 months ago by Larry Garfield — view source

unread

I'd also like to add that I like the 'hands-off' approach that PHP has
taken in the past. I'm not a fan of some of the PSRs. I literally had
someone tell me a few months ago that I would never be a 'real
programmer' because I used tabs instead of spaces which is against the
PSR-12 spec (which is my only deviation from the spec, and why is that
even in the spec in the first place? :sigh:). Luckily for me, I guess,
I think I'm 'real programmer' ... even though it still feels like a
hobby (even 20 years later), but people pay me a bunch of money to do
it and people seem to like my work.

As the person who has recently taken over as Editor for PER-CS (which is the new edition of PSR-12), let me state for the record that person is full of shit and you're welcome to tell them I said so. :-)

That said, people really get fussy about the coding style PSRs/PER, but FIG has done way more than that, and arguably much more important things. :-) But I digress...

--Larry Garfield

11 months ago by Mike Schinkel — view source

unread

On the one hand, PEAR was a single "baseline" that everyone expected; on
the other hand, packages tended to be slow to adapt to new needs and
fashions, and inflexible to different environments. So instead, people
moved to:

Frameworks; which themselves have mostly adopted a "component-based"
approach interoperating via Composer packages

Non-framework groups like The League of Extraordinary Packages
https://thephpleague.com/

Single packages that have become de facto standards - large projects like
Guzzle and Monolog; and smaller utilities that do one task well, like
Ramsey/UUID

There are two ways I can see a "standard PHP package" working:

As a server-wide install, part of the distributed PHP. That inherits all
the downsides of PEAR, but might be appropriate for a fairly small subset
of really low-level functions.

As a set of Composer packages, managed completely outside the PHP
lifecycle, in which case it's not clear how it would be different from all
the packages that are already out there.

There is at least a 3rd way.

There could be server-wide installs with site-root overrides similar to how .htaccess works with Apache where a .php file (or some other name) in the site root could be used to provide overrides for the standard PHP library to allow sites to fix bugs, use a newer version, etc.

This would allow site owners to resolve PHP standard library related issues with sites on managed servers where the managed host will not allow server-wide install to be modified.

Composer seems to be serving the community pretty well for a lot of
functionality.

Except for Composer's lack of ability — by its very nature — to provide a single "baseline" that everyone can expect, a benefit of PEAR you noted above.

There is usually the argument - "if this is not in core no one (people on shared environments/hosting) won't be able to use it" and so on..

Many orgs prefer managed hosting so as not to have to pay for system administer expertise on staff, and few (any?) managed hosts will modify their installs to include more than the few highly popular extensions from PECL.

The counter to that are things like Imagick / redis / memcache(d) / APCu which are vastly popular but still live outside core (obviously those are not language rather than engine features).

The list of extensions managed hosts will consider installing is so small — compared to the hundreds (1000s?) of extensions they will not — so pointing to the few outliers that can live outside core as evidence of developer's ability to address their needs with them is much like arguing the US Constitution can be amended to solve existing political problems.

Technically both statements are correct, but practically speaking neither are realistic approaches to solving current day needs.

OTOH, a standard library in core written in PHP that could allow for polyfills for future C-in-core changes, a lower bar for implementing additions to core (and thus a way to expand those who can actually contribute to core), and a starting place for anything that could be written in PHP to be written in PHP so as not to require updating and testing C code seems to have many benefits. #jmtcw

-Mike

11 months ago by Reinis Rozitis — view source

unread

I have worked with PHP for 14 years now and I know nothing about PEAR. It either says something about me or about PEAR.

Then the next logical question would be do you know what PECL is? :)

But to be short my point is - before attempting to get new function(ality) in core it (seems to me) that more realistic if you really want to achieve that is at least by presenting some kind of working base blocks especially when there are all the means to extend the language both on low level (being an extension) or a pure-php package in any of the existing channels (composer / push for repopulation of PEAR? etc).

There is usually the argument - "if this is not in core no one (people on shared environments/hosting) won't be able to use it" and so on.. The counter to that are things like Imagick / redis / memcache(d) / APCu which are vastly popular but still live outside core (obviously those are not language rather than engine features).

11 months ago by Deleu — view source

unread

I have worked with PHP for 14 years now and I know nothing about PEAR.
It either says something about me or about PEAR.

Then the next logical question would be do you know what PECL is? :)

But to be short my point is - before attempting to get new function(ality)
in core it (seems to me) that more realistic if you really want to achieve
that is at least by presenting some kind of working base blocks especially
when there are all the means to extend the language both on low level
(being an extension) or a pure-php package in any of the existing channels
(composer / push for repopulation of PEAR? etc).

My wish here is not to present a new functionality to core, but rather
start a project which lowers the barrier for getting basic things into
core. Sure, I could write a new Str class and fix all the problems I think
the str and str_ lib has. In fact, everyone can do that [1][2][3][4].
PHP current state actually encourages the language to have multiple
competing implementations for the same thing because some past decisions
are hard to be fixed and introducing things to the language are also hard.
The competition and the diversity addressing all sort of problems is a
strength in the PHP Community, but also a weakness in PHP's ability to
provide a bare minimum that help newcomers to get started and veterans to
only reach for deviation when it is made necessary.

There is usually the argument - "if this is not in core no one (people on
shared environments/hosting) won't be able to use it" and so on.. The
counter to that are things like Imagick / redis / memcache(d) / APCu which
are vastly popular but still live outside core (obviously those are not
language rather than engine features).

rr

--

To unsubscribe, visit: https://www.php.net/unsub.php

I wouldn't argue in favour or against shared hosting. I haven't used that
in a decade so I'm really not the best person to talk about that universe.
If someone were to create a PHP Extension to rewrite some of PHP's
functionality and/or cover PHP's standard library gaps, I know I wouldn't
spend a minute of my time looking into it or installing it. I imagine that
it would take many years until someone could actually build up a reputation
and a library quality until it could start being considered for adoption.

[1] https://github.com/spatie/string
[2] https://laravel.com/api/9.x/Illuminate/Support/Str.html
[3] https://symfony.com/doc/current/components/string.html
[4] https://github.com/azjezz/psl/tree/next/src/Psl/Str

--
Marco Deleu

11 months ago by Lynn — view source

unread

Hi folks!

Reading through https://externals.io/message/120323#120326 and
https://externals.io/message/120323#120332, it reminded me of a few times
I've seen similar debates on internals about "why not do this on userland?"
and the consensus seems to be inclined to only take the maintenance burden
of internals function if there's strong justification for it regardless of
whether there's consensus of being useful or not.

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.

Being official means it inherits the trust PHP already has

Green field development in this day and age often comes with a great set
of automation tests that drastically lowers the maintenance burden

Possibility to standardize a lot of common code that has countless
userland implementations

If we make a mistake of implementing a bad design, the worst thing might
be that we "wasted" a good word in a function or class name. As long as
test coverage is there we can probably just keep it running for many years
with little negative impact other than "yeah, PHP did a bad job at X".

Such a project could benefit from the RFC process already in-place and
voters could take into consideration the lower maintenance burden when
voting for something that they think it's useful.
One relevant downside is that internals might get flooded with RFCs for
filling up some common functionalities for a few years until it dials down
a bit.
It may also lead to re-discussing PHP's entire standard library.

The work to get started seems to be about:

1- Getting an RFC to approve this idea itself
2- Getting a repository to host the PHP package code.
3- CI/CD
4- Release Management
5- Versioning Strategy
6- Package naming convention
7- Distribution strategy (single package vs multiple sub-packages)
8- PHP developers and community contributions

Anything I'm missing? Thoughts?

--
Marco Deleu

A few more benefits:

an official php polyfill package to be forward compatible with new
classes/functions/constants for core php
popular features could eventually be ported to C if it gives a benefit
in performance, or if they are really popular
applications with slower upgrade cycles would have less effort
implementing new php features

11 months ago by tag Knife — view source

unread

The work to get started seems to be about:

1- Getting an RFC to approve this idea itself
2- Getting a repository to host the PHP package code.
3- CI/CD
4- Release Management
5- Versioning Strategy
6- Package naming convention
7- Distribution strategy (single package vs multiple sub-packages)
8- PHP developers and community contributions

Anything I'm missing? Thoughts?

I'm also wondering if we should be looking at including composer as a
default install of PHP.
I remember there being some discussions about it and generally a positive
outcome, but then nothing further being done.

We PHP would do follow this approach providing composer package manager as
default with every future php release, should be a requirement.

11 months ago by tag Knife — view source

unread

An extension of this, Looking on packagist. The namespace PHP is reserved,
in collaboration with PHP, Composer and Packagist. Official PHP packages
can use the /PHP/... root namespace.
And can be published on packagist under the PHP namespace

https://packagist.org/packages/php/ -- Note this URL CURRENTLY redirects
404 not found as nothing has been published under this namespace.

11 months ago by tim@bastelstu.be — view source

unread

An extension of this, Looking on packagist. The namespace PHP is reserved,
in collaboration with PHP, Composer and Packagist. Official PHP packages
can use the /PHP/... root namespace.
And can be published on packagist under the PHP namespace

To my understanding in the
https://wiki.php.net/rfc/namespaces_in_bundled_extensions RFC it was
agreed not to use the PHP namespace and instead create appropriate
top-level namespaces.

The new random implementation in PHP 8.2 is already "relying" on that
RFC: Everything is sitting in Random* and that namespace is now
effectively reserved for it.

There was also this proposal (that did not yet go anywhere) to introduce
the iterable* top-level namespace:
https://externals.io/message/118896#118896

Best regards
Tim Düsterhus