> On May 7, 2020, at 09:33, Dan Ackroyd <dan...@basereality.com> wrote: > > On Thu, 7 May 2020 at 10:13, Rowan Tommins <rowan.coll...@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. > > So although the choice to provide some functionality in core was the > correct choice at the time, it would not be a correct choice to do > now. > > The reason to try to reduce the amount of core code is that > maintaining core code is much more difficult than maintaining userland > libraries. > > There are swathes of PHP core that are scary to fix bugs in, let alone > think about adding new features or refactoring their API. > > Although each removal would need to be justified individually, I think > as a general aim 'more userland, less core' is good.
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. However, we recently rejected the Server-side Request and Response Objects RFC[2], so what is the over-arching philosophy that drives our decisions? I don’t know the answer to this, but I think it might be a good exercise to consider it. It’s probably different for each person here. I think Paul Jones attempted to call attention to this in the _epilogue_ to the “Server-side Request and Response Objects” vote[3]: > The initial impression is that there is a strong desire for work > that can be done in userland to stay in userland. However, that > impression conflicts with the recent acceptance of str_contains(), > which is very easily done in userland. > > **Lesson:** Of functionality that can be accomplished in userland, > only trivial/simple functionality is acceptable. I reject the conclusion (“lesson”) here, but it’s difficult not to arrive at this conclusion based on the observations. It might be interesting to flip this around, though, in the case of the request/response objects vote. Maybe this specific lesson could be better stated as: > **Lesson:** Of functionality that can be accomplished in userland, > functionality viewed as having a high maintenance overhead is best > left in userland. I don’t know whether that’s the correct lesson, either, but I think it helps illustrate that we’re all approaching these decisions from our own philosophical points of view for what should or shouldn’t be PHP, and what appears to be the guiding principle(s) to one may be the opposite (flipped) to another. So, where am I going with this? I really have no idea. I thought I had a point about trying to articulate some overarching philosophy for the direction of PHP, but now that I’ve gotten here, I think I’ve convinced myself that one of PHP’s strengths is that it has no guiding philosophy. Each person here brings with them their own philosophies of how the language should be shaped, and even those philosophies may change and contradict themselves from time-to-time, and that’s what’s made the language what it is today, and perhaps that’s what continues to make the language better. While it would be nice to understand the rationale behind decisions for what goes into core and what comes out, the reality is people are making these decisions and we don’t get things right all of the time, but we do get things right much of the time. I think “Allow trailing comma in parameter list[4]” and “Add str_starts_with() and str_ends_with() functions[5]” might be good examples of this. I’m done waxing philosophical, so what I can say about `uniqid()`? This is one of those functions I think (without doing the research) is used a lot in CLI scripts and tooling. As a result, it may be impossible to do good research on this, since these scripts are probably not available in public repositories. Additionally, when I write scripts like this, I don’t reach out for Composer packages, since I don’t need the overhead of a full-blown project or library, and I doubt others do, as well. This means allowing userland to fill the void left by the removal of `uniqid()` may not be a good option. I think we should err on the side of BC with `uniqid()`. While the manual says it’s been in the language since PHP 4, the research I did in the “museum” shows that it’s been in PHP since 2.0b9 (see the Changelog in the tarball for 2.0b10[6]). Is there any way we can improve this function without deprecating/removing it? Cheers, Ben [1]: https://wiki.php.net/rfc/str_contains [2]: https://wiki.php.net/rfc/request_response [3]: https://externals.io/message/109563 [4]: https://wiki.php.net/rfc/trailing_comma_in_parameter_list [5]: https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions [6]: https://museum.php.net/php2/php-2.0b10.tar.gz
signature.asc
Description: Message signed with OpenPGP
