Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106165 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3307 invoked from network); 8 Jul 2019 14:35:56 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 8 Jul 2019 14:35:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1563191719; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=yUx8TCj0Di1L3ZxqjvbCwo zHQ5VPf5rRTmA+onVqMyA=; b=jyxslPicIQKWs9oKqcz+pQVEPbCiBmxHYvg8Ex 6NG5PL3V+GJk1xyHle3GV0bTD43xnMlaBOmk6JlH0Sg8Q9xhuXA9KrCu43SIpbq+ aNBkBwp2hR2Fq4u9FjHlojrsblmJgChCUEGcpXgJnZTZfuD94/eu4xYJRrFq9nu3 AgGKo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=turbo-smtp; d=php.net; h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type; b=yP+YK+Py93p34F6ilBKIn8qiE+jXfz0wTXb2ewxkm2iQVV0baOc1/3L6QP3pVQ b/1CXpMDiiqprIjhqaRcEC2RqaCtg+7f4yTWaLeRjFIxKhlqGhwT4vEoct1ShBXh aWhBcV2fTxxl3efjnjwlrHp3+MnTnqHDeIgJi3lzoEGLg=; Received: (qmail 11456 invoked from network); 8 Jul 2019 11:55:19 -0000 Received: X-TurboSMTP-Tracking: 5146419819 X-Gm-Message-State: APjAAAWd2H+hkNduPK5ZmyzAZpZqu2a1lOVj/VbKZcyqHqrS29bMP96w qbaLtobmEjR4NIJ+JtQt5ralrGD6TDe0sMWnZHw= X-Google-Smtp-Source: APXvYqxQBgn+Sq6o/eDT+ZTOduY/tYx6P3HWEN+JP0/toig32+veK6p4Sg6sR4oeR19SdDqmWIBEsymt5G0Jgn+VKeY= X-Received: by 2002:ad4:5250:: with SMTP id s16mr14692131qvq.50.1562586919078; Mon, 08 Jul 2019 04:55:19 -0700 (PDT) MIME-Version: 1.0 References: <09a8bba3-d17a-a8e5-f9b7-cc3d65f1e66c@gmail.com> In-Reply-To: Date: Mon, 8 Jul 2019 14:55:07 +0300 X-Gmail-Original-Message-Id: Message-ID: To: Nikita Popov Cc: Stanislav Malyshev , Kalle Sommer Nielsen , Internals Content-Type: multipart/alternative; boundary="0000000000003e11a2058d2a1e16" Subject: Re: [PHP-DEV] [RFC] Deprecations for 7.4 - specifics From: zeev@php.net (Zeev Suraski) --0000000000003e11a2058d2a1e16 Content-Type: text/plain; charset="UTF-8" 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. 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. Why are we proactively making the lives of users more difficult for literally no gain at all? Zeev --0000000000003e11a2058d2a1e16--