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. > 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. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
