Just a note on process. It is not necessary to hold multiple RFC's:
> For procedural reasons, multiple RFCs may be combined into one, in which case there may be multiple primary votes. > Combining multiple RFCs into one does not allow turning a primary vote into a secondary vote. In general, something is considered a primary vote if it could be conducted independently of other primary votes in the same RFC - ie, it is not an implementation detail. So, what we have here is multiple primary votes ... [1] https://wiki.php.net/rfc/voting Cheers Joe On Sat, 22 Jun 2019 at 09:23, Kalle Sommer Nielsen <ka...@php.net> wrote: > 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 > >
