Hi! > 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:
It may be supported by other extensions (btw did anybody verify that it actually is and gives the same results?), but this is not the reason per se to remove old working functions. There's a lot of duplication in programming languages - all (Turing-complete) languages ultimately do the same thing, and most practical languages have way more syntax and utility functions than strictly necessary to achieve desired outcome. This is because redundancy in expressiveness improves productivity. Here we have the reverse - we are forcing people who have working code to go back and rewrite it to essentially achieve the same result we already have - negative productivity. I don't see a point in doing this. > 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 It works. > 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? I see multiple references to it in code online. If it works for people that use it - why touch it? I even see porting it to other languages, like Javascript. Pretty weird for a function that nobody ever needs, isn't it? > 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 I don't see it as a complaint at all. "Library provides many functions" - this is a *complaint*?! This is pretty much why PHP became popular! I know there are people online that enjoy writing nitpicky snide articles about how PHP is "inconsistent". I say - let them. Internet is big, anybody can write anything, it's not a reason to take to heart everything random people on the internet write. Satisfying those people - some of whom aren't even PHP users - is infinitely less important than the time of actual PHP users that actually use the language. And I do not see who of the actual PHP users these removals would help. "Consistency" is only helpful when it improves something and makes work easier. Nothing is made easier by removing functions that work. > 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. It is very common in virtually all programming languages to have utility functions to support special cases, even if there's a library that supports more generic case. You have your regular expression library, and then you have functions that parse dates, or numbers, or phone numbers - even though regex library alone enough to implement those. It is a very common and standard practice. Moreover, we're not talking about introducing new functionality here - we're talking about removing functionality that people *already use in their code*. The bar for this should be super-high. In fact, excluding clear blunders like magic quotes, etc. if we never ever removed a working function, I'd be fine even with that. But if we decide to remove, it should be for reasons far better than "you can do it with other functions" - that never was the PHP way and shouldn't be. > We have a large set of aliases that easily can make the standard > library feel convoluted and therefore also creates a certain technical What you call "convoluted" I call "convenient and versatile". Having many functions to help people do what they need is good. We don't pay per function. There's no goal to have as few functions as possible. > 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. I don't see how this is "evolving", if you understand evolving as getting more fit for the purpose. I do not recognize "having as few functions as possible" as a goal worth pursuing, so what's the point? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
