Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106177 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 49227 invoked from network); 8 Jul 2019 17:18:12 -0000 Received: from unknown (HELO mail-lf1-f67.google.com) (209.85.167.67) by pb1.pair.com with SMTP; 8 Jul 2019 17:18:12 -0000 Received: by mail-lf1-f67.google.com with SMTP id c19so5479260lfm.10 for ; Mon, 08 Jul 2019 07:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VAGZ8QMe7jgMgYZUFnpNbWBir6AQzyyrPJzcv2KUda0=; b=eRdRVg/FqA0al5vBmgFNvCmOO+LBYkutlRb17FZ/cHZAJ1F5SAomO+QNiYR6/dG6fu IfO8Zccfhr+yECjiHNISNXUhqNRG5BnAma200HL37r7gEJEz5KiN8hpc5fCEwyk2S/1k tLAeXFvjKKmdtgAXUjZdCjynnlKY0I8kRhCrgZw3wUQf0UEhA8dN18FZcqEKgbBFTU8V EIvsmHPjvkRDYryRaznooc4Pp92znKDSWxS1PZRhIzvL2ODJvLyvH1Flm2Ut19pwBgTS kXrWYb3pceJkni6zU5oD4PmLXLmomM6Gr59SuWCZ1lM6iHoB0VMVJ5T6oHZyDPNgMlQR hmDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VAGZ8QMe7jgMgYZUFnpNbWBir6AQzyyrPJzcv2KUda0=; b=rNsKsjX3qL+IAOOH9mIjklmvw7toZnWLJoXLOcKQPqIBk360gV2qYMEvz7grsOuN0h q9f9+m7S/SnS61xkyH6oYLus5IxVMMurHXwvqv1XobgSgybglbUHLHwbfZBqX52De1NU OnyePNZx/7ApAyboEk1i72+T7nXk1kPJakUxKVGqDLH8HCY7KWHOfJaHEvSzCOzP5BUm 0q0i8IWV6voI8nWuVK0ULF6h7JQQ35nd2QL+0180EswvXX5yBgT/zloCvnFIXPQ5dpDh tnfxFgNwm9+lMXqIcS8xtEGeOkSXQIKUrng/Kq3lLDw+K3FwaKDral5j0reThyr5wjFy Xmvg== X-Gm-Message-State: APjAAAUR0yJbZR463CyIj8vwgoHWHaucrUHVlTKhbSugcwWfe90dAZwL fhs/EvBpu7bx13ZIn28YN5AaIAbYw3QDioQA92I= X-Google-Smtp-Source: APXvYqw4mv7BArTxytJKSEVrIG4WBKEX/A0dU55CQ2u8YFQ09qNxssjZVs4Lda2uCyn1dABsvhTsEXfxj6Wso0KZoik= X-Received: by 2002:a05:6512:21c:: with SMTP id a28mr9064538lfo.14.1562596656704; Mon, 08 Jul 2019 07:37:36 -0700 (PDT) MIME-Version: 1.0 References: <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com> In-Reply-To: Date: Mon, 8 Jul 2019 16:37:20 +0200 Message-ID: To: Zeev Suraski Cc: Stanislav Malyshev , Kalle Sommer Nielsen , Internals Content-Type: multipart/alternative; boundary="000000000000a67437058d2c62bf" Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4 - specifics From: nikita.ppv@gmail.com (Nikita Popov) --000000000000a67437058d2c62bf Content-Type: text/plain; charset="UTF-8" On Mon, Jul 8, 2019 at 4:01 PM Zeev Suraski wrote: > > > On Mon, Jul 8, 2019 at 3:38 PM Nikita Popov wrote: > >> On Mon, Jul 8, 2019 at 1:55 PM Zeev Suraski wrote: >> >>> >>> >>> On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov >>> 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 --000000000000a67437058d2c62bf--