Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111195 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 29146 invoked from network); 26 Jul 2020 19:36:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Jul 2020 19:36:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D28221804B4 for ; Sun, 26 Jul 2020 11:32:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 26 Jul 2020 11:32:16 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id z18so9151017wrm.12 for ; Sun, 26 Jul 2020 11:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=hpZhs/wveI8OdzIC0HKkB0m6RsPPC5G+SKzYCWgSu7g=; b=r1/IZjOI8VZWlQGRjEH7qrAHoD7+5QDqkuXCTKiVehoJ271k4iapnLsghUIrF7zr9L zyyIwLHH2bSkvfoXiBOAoA6qgaWz7krrYdk3Le4I8lV9i2MAb0mQboOuJh8PcE0LDfMS H6WmfMRHTKCHGUihy6bTr/4U0ORk8ieEx6ReOkNh5EC+5mq1sqOKZxYVyjCBboByBMDn lW4NkJKomkonGNcUYZ1bcB21poW9rVRH/mKAAVOb+PLHKgQh4R7yjYkPdKqeZjRmgdnM MdmuzEzYBRp8+7byTMn4g6WXBideU8DOvF2BmPXRSRdy19P2zKWCe0DLI+y3jmbbH9s6 2e9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hpZhs/wveI8OdzIC0HKkB0m6RsPPC5G+SKzYCWgSu7g=; b=W8OprtzaGyhgxKbfqAR4rEd5271IKbPrJdXUvy5MxsC5DA4ZeOw3p8j1dReytGTuPG TfiEbnkp+yFdLTOXoxpqHPVvvA12SP7mVIRa+ecJ1eJNT53D5EWi5u6rbMq/AXYyUg1m saWu/m8S58oOB+ApHQgH4/Gu1tfgt5SrekhAiAPkqS2AlRu6JQhOW2c4PzfHIpidAy8P JVkaoS1Vqoud0dOoV1SDiFsRRXfRGYcgV8xHBPtLG+rJf6Ien82tfcVt++fhhFqTkOYw /BSuMrM6YgQ7ZZOJUo/5OUCL+LBL8oCixAcrzcFI4ipODbfZxPjdhx+b96ty/D5Zhe/k nDZw== X-Gm-Message-State: AOAM530aMpk5kLDmRmk4S1pYD9FhQSVXZi1SudSN+TLnmqsqlsg8psP9 R5zSs50chTi4t26/07Fd+O/ojZoR X-Google-Smtp-Source: ABdhPJyYKkEECCgVl2M/WI4voPOWdBVuKe6GoYFnyS6XeUTTrstYSnlzXj0JAvdHIK3P99bI1dy+dQ== X-Received: by 2002:a5d:498f:: with SMTP id r15mr18466617wrq.175.1595788334799; Sun, 26 Jul 2020 11:32:14 -0700 (PDT) Received: from [192.168.0.22] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id q3sm14498088wmq.22.2020.07.26.11.32.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Jul 2020 11:32:14 -0700 (PDT) To: internals@lists.php.net References: Message-ID: <0bba3669-ce0a-068e-d3ed-28fa5605e03f@gmail.com> Date: Sun, 26 Jul 2020 19:32:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters From: rowan.collins@gmail.com (Rowan Tommins) Hi Chris, On 26/07/2020 14:52, Chris Riley wrote: > Thanks for the feedback so far. In light of the feedback received both here > and privately, I've made 3 changes to the RFC document Firstly, a reminder of the guideline in the RFC howto that the link to the RFC should be included in replies, which is particularly relevant when announcing changes to the text. For others trying to find it, it is here: https://wiki.php.net/rfc/renamed_parameters Secondly, regardless of the merits of your proposal in itself, I think an RFC in this position should explicitly state why it is proposing to re-visit an accepted feature. I can think of a handful of possible reasons, but none seem to apply: - If new concerns have come to light which are likely to change the opinion of those who voted Yes. This is not the case for the concerns in your introduction. - If the RFC passed only by a narrow margin, or a low turnout, and this version is expected to gain a larger majority. The RFC passed with a ratio of 3:1, with 75 votes cast [1]. - If the RFC discussion was rushed, so that people did not have adequate time to understand the proposal and discuss its implications. The RFC was informally resurrected at the start of April [2] and formally at the start of May [3] and saw plenty of discussion. - If there is evidence that people voted Yes despite reservations that this proposal resolves. No evidence is presented of this, and the only message of that sort in the voting thread expressed reservations unrelated to this proposal. [4] - If there is evidence that (a significant number of) people who voted Yes have now changed their minds having re-considered the implications. No evidence is presented of this. As Benjamin says, the pragmatic way forward would be to discuss enhancements on top of the accepted feature, rather than last-minute alternatives to it. [1] This appears to be the second highest turnout after Scalar Type Declarations, according to https://php-rfc-watch.beberlei.de/ [2] https://externals.io/message/109549 [3] https://externals.io/message/110004 [4] https://externals.io/message/110910#110961 Regards, -- Rowan Tommins (né Collins) [IMSoP]