> Le 22 juin 2019 à 09:22, Kalle Sommer Nielsen <ka...@php.net> a écrit : > > Hi > Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev > <smalys...@gmail.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="rtl" > lang="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. >
PHP has indeed a sheer number of old-school functions and of niche functions, but as developer, they don’t bother me as long as I don’t see them. One occasion where I am bothered, because I see them, is when I explore the manual in order to find a function that does some job. Let’s take for example the Session Functions: https://www.php.net/manual/en/ref.session.php <https://www.php.net/manual/en/ref.session.php> In the Table of Contents, functions that are actually useful (e.g., `session_start()`) are intermixed with legacy functions that relate to some obsolete way to handle session variables (e.g. `session_register()`). For the particular case of Session functions, there is *some* progress since few years ago (the days of PHP 5.2), because obsolete functions are clearly marked as such on their individual documentation page (https://www.php.net/manual/en/function.session-register.php <https://www.php.net/manual/en/function.session-register.php>; although the pink Warning box ought to be at the very top of the page, so I’m not in danger to actually read the documentation before realising that it is obsolete). But the Table of Contents still needs to be reorganised... Now, let’s take the manual of String Functions: https://www.php.net/manual/en/ref.strings.php <https://www.php.net/manual/en/ref.strings.php> Those may be separated in two groups: the first one for those that are recommended/useful for modern code, and the second one for legacy functions such as `convert_cyr_string()` and `hebrevc()` that provide functionality that are hardly useful today or that are better handled by some other mean. Moreover, for each of those functions, a pink Warning box might be placed at the very top of their documentation page, stating that such function is probably not useful or recommended for new or refactored code, and pointing to better alternatives when appropriate. *However*, such documentation improvement, does *not* imply throwing a deprecation warning each time the functionality is used. There is no issue for legacy code base to continue to use it as long as it is not broken, and as long as I don’t see it. —Claude
