On Mon, Jul 8, 2019 at 1:55 PM Zeev Suraski <z...@php.net> wrote: > > > On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov <nikita....@gmail.com> wrote: > >> I have now made the following changes to the RFC: >> >> * Removed enable_dl deprecation. The fact that dl() is currently >> available >> by default on CGI, which is a server SAPI, makes this more dicey and needs >> more careful consideration. As this RFC needs to go to vote today, I'm >> going with the conservative option of dropping it from the RFC. >> * Removed register_argc_argv change from the RFC. This was not really a >> deprecation, so does not belong here. We'll likely just want to make the >> necessary changes in PHP 8. >> * Removed the INPUT_SESSION + INPUT_REQUEST deprecations. These have been >> warning since forever, so going through an additional deprecation phase >> makes no sense. I went ahead and removed them in PHP 8. >> * For the deprecation of implode() with inverted parameter order, >> explicitly point out that the single-argument form is not deprecated. >> * Various text improvements that do not change the content of the RFC. >> >> I will start voting on this RFC later today so we make feature freeze. >> > > Nikita, Kalle, > > None of my feedback was even responded to. > > There's something fundamentally flawed in the way deprecations are being > treated. If there's no compelling case to deprecate, we shouldn't > deprecate - it's that simple. Someone's (or even many people's) opinion > about the standard library is not a compelling reason. That can be a > reason not to add something new - but absolutely not to remove existing > functionality and break users' code. > > convert_cyr_string(), hebrev() and hebrevc() shouldn't even be considered > for deprecation. They don't clear the most basic requirement for > deprecation - which is having some sort of negative impact to keeping them > / positive impact from removing them. There is none. It shouldn't even be > up for a vote. >
I've read your feedback, but didn't feel that a response would be productive. There's a difference in philosophy here that we have already discussed many times in the past, and I don't think discussing it one more time will change things. There are broadly two reasons to deprecate: The first is to remove technical debt in php-src itself. The second is to discourage bad practice and encourage migration to better alternatives. You clearly do not see value in the latter, and I can certainly see where you're coming from with that, but please let people make their own value judgement here, rather than saying that it "shouldn't even be considered". is_writeable() should also be removed from the list as contrary to the > premise of the RFC, it is not a spelling mistake ( > https://en.wiktionary.org/wiki/writeable / > https://www.dictionary.com/browse/writeable). Even if it was - it's > hardly sufficient enough a reason to deprecate it. There's zero, absolute > zero upside from deprecating it, so it doesn't clear the basic requirement > for deprecation. This one is probably the least important one from the > list since the fix is easy (unlike the ones above - where it's anywhere > between a small and very big headache). Still, it's based on a bogus > premise and there's simply no reason to do it. > I went ahead and dropped this from the RFC. Quite a few people have expressed concerns about this particular deprecation -- it almost seems like a religious question... Nikita
