On Mon, Jul 8, 2019 at 3:38 PM Nikita Popov <nikita....@gmail.com> wrote:
> 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. > Some of my feedback could be attributed to different philosophies, but certainly not all of it. I have to say, both in the previous time you mentioned that 'a response would not be productive' and this time around, even if that's not what you meant (and I certainly hope it wasn't) - I found it quite insulting. I didn't object to the entire RFC, provided both focused feedback as well as constructive (IMHO) proposals to how we can potentially create a situation where both 'camps' are happy. Is it really sensible to simply ignore it? Should we move from RFC's to PDC's (Please Don't Comment)? 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". > I absolutely do see value in discouraging bad practice. I was one of the key supporters of deprecating safe_mode, and if I recall correctly also magic_quotes - two of the worst practices in PHP's history that were *huge* compatibility breaks. Andi and I reinvented the PHP object model at a huge compatibility breakage cost, because it was the right thing to do and fostered much better development practices. So please, don't characterize my view as 'clearly not seeing value in discouraging bad practice'. A better way to describe it is that my bar for defining 'bad practice' is slightly higher than the virtually non-existent one used for some of the deprecation proposals in the RFC. Deprecations, unlike introduction of new features - aren't a case where we can simply let "people make their own judgement". That makes sense when introducing new features. But when deprecating feature - this is a surefire recipe for a tyranny of the majority. That's exactly why the Project's DNA should be respected, instead of trying to push anything and everything for a vote. True, it's not explicitly spelled out as a ground rule, but it's very strongly implied here, in the voting RFC: "Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible the purpose of the vote is to ensure that there's strong support for the proposed feature". Obviously, 'for the most part' is up for interpretation - but the intention is clear - breaking things should only come if there are substantial, tangible gains. That's how it's always been, and that's how it should continue to be. We can perhaps turn it into a harsh requirement (such as 95% vote), or we can stick with only pushing forward proposals that bring real, tangible value. I think even you would agree that this isn't the case for at least some of of the deprecation proposals, and as such, I very much stand by my position that the deprecations in the list that bring virtually no gains other than 'we think people are better off doing it differently' should simply not be voted on. Moreover, at least in on case here - there's simply no objectively (or even subjectively) better way of doing things - the RFC is simply stating that "people should not be doing this at all in 2019", even though the authors are clearly not domain experts in that topic (please pardon my assumption and correct me if I'm wrong). I'm not aware of any better alternative to using hebrev() in a context where it's needed. Both Stas and I provided examples/indicators that it is in fact, still being used - even if it's not as common as it was in 1998 and probably used mostly outside the context of HTML (which, by the way, makes the whole W3C quote about what should or shouldn't be used in HTML irrelevant). > 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... > Thanks, although it is indeed the least problematic deprecation on the list in terms of the headache involved in dealing with it. Zeev
