Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115082
MIME-Version: 1.0
References: <012901d7683a$446a7ba0$cd3f72e0$@gmail.com> <CAESVnVrFX9MWBQZPnkas+hJBgatOsuT_g1wpOcDstcD09+qASg@mail.gmail.com>
 <C58053AC-0692-4E40-AEFB-D60893665588@newclarity.net>
In-Reply-To: <C58053AC-0692-4E40-AEFB-D60893665588@newclarity.net>
Date: Wed, 23 Jun 2021 17:51:09 -0500
Message-ID: <CAESVnVo78NNaOKCQt27y0AN6Jysw2DHFWUOoTkToh+Onj7EZUw@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: "G. P. B." <george.banyard@gmail.com>, Hamza Ahmad <office.hamzaahmad@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bc87c805c576be82"
Subject: Re: [PHP-DEV] Introduce str_left/right In 8.1
From: pollita@php.net (Sara Golemon)

--000000000000bc87c805c576be82
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 23, 2021 at 2:10 PM Mike Schinkel <mike@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.

--000000000000bc87c805c576be82--