On 24/03/2022 09:52, Christian Schneider wrote:
If these functions were proposed today, under better names but the same feature
set, I don't think mbstring being optional would be accepted as reasoning for
adding them to core. So the only reason to keep them is if they're widely (and
successfully) used, which I've not found evidence for.
This argument is somewhat broken: Not adding something because an alternative
exists is not the same as removing something (requiring code changes) where an
alternative exists.
Absolutely, and an earlier draft of my e-mail said that more explicitly,
but I edited for conciseness. I was trying to make the distinction that
we wouldn't want to tell new users "if you want to measure the length of
the string, install ext/strlen"; but telling new users "if you want to
convert encodings, install ext/mbstring" is probably reasonable.
You are absolutely right that that does *not* apply to *existing* uses
of the functions, and there will be some proportion of users / libraries
who were previously using these functions successfully, but do not have
mbstring installed / required. I think the usage is low enough, and the
install base of mbstring is high enough, that that won't affect many
people; but it's hard to prove that conclusively.
In the end, we have to weigh two costs: the cost to *new* users of
leaving these confusing functions in place; and the cost to some portion
of *existing* users of forcing them to change their code, and possibly
install ext-mbstring (or some alternative). Doing nothing is not
automatically better.
I have one issue with the wording in the RFC: While “Function utf8_encode is
deprecated; check usage is correct and consider mb_convert_encoding or other
replacement.” suggests to replace it, the part about checking the usage implies
that if someone is sure about the correct usage it is fine to keep using
utf8_encode(). But as the proposal wants to remove it for 9.0 I think this is
somewhat misleading.
That's a fair point. The intention was to encourage people to look at
whether they were using the function right in the first place, not
blindly replace it with mb_convert_encoding, since the whole point of
the deprecation is that they probably aren't. I'm not sure how to
concisely say "replace with mb_convert_encoding if you actually need to,
but maybe you can just delete this function call and your code will be
better".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
