On Mon, Jul 8, 2019 at 4:01 PM Zeev Suraski <z...@php.net> wrote: > > > 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). >
I'm certainly not a domain expert in RTL languages. I'd be happy to drop hebrev() from this RFC if someone can bring forward a good technical argument as to why these functions are still necessary and where they would be used. However, and given your comment here I may have just missed this between other mail, I have not actually seen any technical argument on this topic. The only thing I found was a namedrop of "IBM i" without any explanation of the significance this has for Hebrew text or the hebrev() function. (To be clear: I'm not interested in whether it's still used, I'm interested whether it's still used *for good reason*.) Nikita
