On Sat, Jun 22, 2019 at 10:23 AM 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: > Kalle, I see very few ways in which you'd be able to convince anybody whose code was impacted by these removals that they're better off having to audit their code and learn new library semantics - instead of, well, doing nothing. I view this in the same trend as the deprecation of short_tags - deprecations that may make us feel good, make for a 'more proper' code base, and bring hassle to our userbase while aiding absolutely no-one in the process. > 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? > Simple - it harms nobody to keep it, and removing it aids nobody. > 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've seen hebrev() used as recently as a couple of years ago and given that I'm not very active in the local community - it's probably still being used in all sorts of use cases when interacting with old legacy systems (e.g. IBM i). How are you assuming it's not in use? 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. While I've heard the former complaint very frequently (and I agree with it entirely), I've quite literally *never* heard the latter complaint. Not once. Niche functionality doesn't bug anybody. Inconsistent core functionality bugs mostly everyone. Bundling the two as if they're the same, or even similar - is wrong. Niche functionality isn't in the way of anybody - and while it's mostly of no use for most people, the few people who do need it would often be remarkably thankful for finding it available (hebrev() certainly falls in that category). These functions have zero negative footprint - they consume virtually no memory, they don't slow anything down, and I'd feel very confident arguring they do not pollute the namespace in any meaningful way (if anybody here ever bumped into someone that was upset about hebrev() being taken, please raise your hand). Instead of removing functionality that most find useless but some found invaluable - why don't we introduce a new extension, 'legacy', that will include these functions? It can even be disabled by default. That way we don't needlessly and pointlessly make the upgrade path more difficult - or at least, we make it just marginally so (you'd be able to eliminate a class of needless compatibility breakages that would otherwise send you auditing and researching new ways to do exactly the same thing - by simply turning on an extension). 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. > Again, I think our standard library certainly suffers from defficiencies - but I have a hard time accepting that niche functions is anywhere near the top of that list, or that it's even on it to begin with. The key problems of our standard libraries are inconsistencies in naming, inconsistencies in argument definitions and sometimes inconsistencies in behavior. Personally, I think we should actually consider tackling these with a newly designed standard library that would be available via a new top level namespace - *without* interfering with the existing one - which perhaps we can then deprecate by 2030. That would actually bring tremendous value to end users, unlike some of these deprecations. To summarize: 1. Reconsider the proposal to deprecate useful (albeit niche) functions like convert_cyr_string(), hebrev(), money_format() and others.. These deprecations bring virtually zero value but very non-zero headache to affected users. I've yet to bump into a single person, ever, that told me how happy they were with version X.Y deprecating feature Z. Complaints? That's a different story. 2. In case you do want to move forward with them - consider moving them to a new 'legacy' extension instead of outright removing them. Perhaps this can be a solution for short_tags as well, and it can also be a longer-term compromise between the motivation to 'clean up' the language, and the hassle it inflicts on our users when they want to upgrade (which results in longer upgrade cycles and consequently worse security overall). 3. I think we'd all be better off focusing on the real deffficiencies of our standard library. Deprecating's easy, but it's also not very useful. If we can introduce a new, fixed standard library in PHP 8 - it can be a game changer. Thanks, Zeev
