Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106167 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 12223 invoked from network); 8 Jul 2019 15:19:11 -0000 Received: from unknown (HELO mail-lj1-f171.google.com) (209.85.208.171) by pb1.pair.com with SMTP; 8 Jul 2019 15:19:11 -0000 Received: by mail-lj1-f171.google.com with SMTP id m8so6250360lji.7 for ; Mon, 08 Jul 2019 05:38:35 -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=EWIbYBJjMxBvLQshepKdaanBPnYnM7T4C+xPp2Kq2BY=; b=gnA28+HobewGjQgdCIk6xV3aXAwqDWkEq7XFalFojNdM/nadm7xzNzGEPqDdwi9RMP GYXLkmc4fqJL3jLhdPNheje4VJ2AfO2EM85VEZn5o6TrQoHqeNLdoNUSmn61yeDkEbn8 0qNQ4uokbMi4HWaPByczLHEY3ZY0QzvU5AkYEW1lCfbOhrWYkSNvy/vb7mzRt6Tv32yC Exe70U8YOeDG2CrhGJXTRJ2+Hsh5Bk3+oDsQSg7045+XrW6d9jdEAdu6qX35lR/+AQHC 0hTfKQnQPPO5zpjK/p0Pk0Xj0UCel9xlpuXz+ovf9Oi/Zo2621YSnEpq4V/w5wuWRFVR DBkw== 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=EWIbYBJjMxBvLQshepKdaanBPnYnM7T4C+xPp2Kq2BY=; b=XNwF5GK6ynFCZ33Yd9P7kL1CfFcfurYgr2brDV7Z3TfWRPd0foWTHxaJbinkENsVtr UiVbam4J6Jbw5VgcEHq8laIwhvNu+JdF3I0L+sRHE4rxkuO8y5y6gGmCqYzamg8oJbI1 NW6jK90zgglG4GhczFzy6BZBzkUQb/5Ybzf5or+fJ9IzdlOqyBFm2WFYMPitamVWLzDL GFB+w0fxWGErRasdGHuilWgxDYRcnB9trNxX1ue6RPqQ7xItyN9kfeENTIaAxHiSFPWp TmAxOq1J25LjHh/0eTxpamoxF0WJemQLJQWJ5dwKpDsI8qQrJFdOGZdmLYcqTMN0pU9e T//A== X-Gm-Message-State: APjAAAVqWExtfgDnwSb4FUMhsA7UeXGGkxjpozuLq0wEz3KBNNjIBKe5 oTTv7NHoQoFWx/GJZPpkrd2NqMnEjsADk6e0HxE= X-Google-Smtp-Source: APXvYqwBQ4eqXL7t9PDy9TBFp2HbQJzpnN4njP4/sM1j4EOnlEXCdUnrskzNBv4hWHIrjPKw8NU8Wldd6//XUXxEWTA= X-Received: by 2002:a2e:9685:: with SMTP id q5mr10067004lji.227.1562589514822; Mon, 08 Jul 2019 05:38:34 -0700 (PDT) MIME-Version: 1.0 References: <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com> In-Reply-To: Date: Mon, 8 Jul 2019 14:38:18 +0200 Message-ID: To: Zeev Suraski Cc: Stanislav Malyshev , Kalle Sommer Nielsen , Internals Content-Type: multipart/alternative; boundary="000000000000f5f71f058d2ab84a" Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4 - specifics From: nikita.ppv@gmail.com (Nikita Popov) --000000000000f5f71f058d2ab84a Content-Type: text/plain; charset="UTF-8" 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. 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 --000000000000f5f71f058d2ab84a--