Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106022
MIME-Version: 1.0
References: <CAJW__o0GLjcagzF0ZpEK54yyhkFpgV6tm4p+ihnZvv-dC3YFUQ@mail.gmail.com>
 <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com>
In-Reply-To: <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com>
Date: Sat, 22 Jun 2019 10:22:48 +0300
Message-ID: <CAJW__o1pFnhtvyX5prNFV--PWNdb3deopwky1aRzY-bPuuA9bQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Internals <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4
From: kalle@php.net (Kalle Sommer Nielsen)

Hi
Den l=C3=B8r. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <smalyshev@g=
mail.com>:
> My first question for many of those is - why? I.e. it deprecates a bunch
> of niche functions. Most people do not use these functions, so they
> probably don't care. Those they do use them would find their code broken
> or produce new warnings and needs to be changed. I have hard time
> identifying whose life would be made better by these changes.
>
> Now, if some of these functions are hopelessly broken or have no valid
> use cases - like magic quotes - then phasing them out makes sense, and
> the audience whose life can be made better are people who use those
> unaware of them being broken, or plan to use them and would thus have
> broken code unless we warn them (or remove the functions, eventually).
>
> But for functions that work just fine, I see absolutely no reason to
> introduce friction without any apparent upside.

While I understand where you are coming from on this, I do think that
functionality that is better supported by dedicated extensions to do
the job instead of providing some functions in the standard library
that converts from a few specific encodings to another:

convert_cyr_string() -- This uses a non standard set of encoding names
and only for cyrillic like encodings, what justifications is there for
keeping this in the standard library over using ext/intl with
UConverter that supports a much larger set of encodings in a much more
generic way for more than just cyrillic encodings?

hebrev(), hebrevc() -- These functions were designed for the web era
pre IE6 where some browsers did not support <html dir=3D"rtl"
lang=3D"he">, what use case is there for these now that the web has
evolved so much in the past two decades since these were added to do
this on a backend?

One of the biggest complaints we have in regards to the standard
library is that it is inconsistent, it provides very niche
functionality that is better supported elsewhere. I think it is a
perfect opportunity to review these legacy blocks and direct users to
better alternatives instead of us having to support many ways of doing
the same thing. Why should the standard library support only a subset
of conversion functionality that is so niche and already supported
much more fluently and abstract in extensions dedicated for the
matter. I personally think that is a very valid reason to consider
these functions for deprecations.

We have a large set of aliases that easily can make the standard
library feel convoluted and therefore also creates a certain technical
depth as a side-effect. The cost of having to convert these functions
is a small price to allow the language to evolve in my honest opinion.

> For the specifics, I think things like removing allow_url_include
> requires separate RFC. It's a serious functionality change, and bundling
> it with 20 or so other changes would not allow to properly consider it.
> In general mass-change RFCs usually are not very conductive to properly
> discussing each specific change, but mixing changes of different types
> makes it even worse.

I will have a chat with Nikita regarding this.



--=20
regards,

Kalle Sommer Nielsen
kalle@php.net