On Wed, Jun 23, 2021 at 2:10 PM Mike Schinkel <m...@newclarity.net> wrote:
> I have frequently heard the justification of maintenance burden mentioned > as an objection to adding specific features. And in many cases, it is easy > to see why future maintenance burden would be a concern. > > However, it *seems* in this case that these functions are so trivial to > implement that once written and documented they would likely never need to > be touched again. But as I do not yet know the internals of PHP I obviously > do not know that to be a fact. > > Honest question: Would you mind explaining the type of maintenance > required for simple functions like this? What is likely to change in the > future that would require maintenance? And would you mind giving a few or > at least one example of a trivial function that did need to be maintained > after it was written? > > Honest answer. I won't personally feel any pain from adding these functions. No more than I felt when str_contains() was added over my objections. Nobody maintaining PHP will feel significant burden from them. They'll sit in ext/standard/string.c doing their trivial work, opaque to the jit, and they'll get used or not. If cluttering the kitchen sink with one more unwashed utensil makes someone happy, then fine. I'm not going to vote for it though, because it belongs in composer/packagist land, not in core. I've listed the reasons for this in the str_contains() threads, feel free to reference those, they're still valid and correct. -Sara P.S. - I don't actually think the octet versus codepoint versus grapheme argument can be particularly persuasive given that our core string functions aren't encoding aware in the slightest. That ship has sailed. It is, however, another argument for doing this in userspace where the tradeoff is far more obvious, and dealing with alternative multibyte engines and/or polyfills is much more facile.
