Re: PHP Package for PHP

On Thu, May 18, 2023, at 5:34 PM, Rowan Tommins wrote: > 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: 1. 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. 2. Application level tooling that almost every app needs. Logging is the obvious example here. 3. 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. 4. 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. 5. 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