Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117346 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 40437 invoked from network); 16 Mar 2022 07:52:53 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Mar 2022 07:52:53 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 64C8E18053C for ; Wed, 16 Mar 2022 02:17:50 -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=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS1836 195.49.0.0/17 X-Spam-Virus: No X-Envelope-From: Received: from darkcity.gna.ch (darkcity.gna.ch [195.49.47.11]) (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 ; Wed, 16 Mar 2022 02:17:49 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:1210:2ea4:cf00:100c:d908:fc69:af84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id AF10F1516681 for ; Wed, 16 Mar 2022 10:17:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Wed, 16 Mar 2022 10:17:48 +0100 References: <4724184.31r3eYUQgx@come-prox15amd> <37421f61-4e2e-53d3-56d0-022a3c21ed2e@gmx.de> <4f8bad56-267a-9279-1e57-66fd10b8874f@gmail.com> <6230f8bf.1c69fb81.b1e54.162dSMTPIN_ADDED_MISSING@mx.google.com> To: PHP internals In-Reply-To: Message-ID: <43EC1ECF-3E73-4A32-A9FE-056B619B4A6B@cschneid.com> X-Mailer: Apple Mail (2.3696.80.82.1.1) Subject: Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion From: cschneid@cschneid.com (Christian Schneider) Am 16.03.2022 um 10:00 schrieb Mark Randall : > On 15/03/2022 23:02, Patrick ALLAERT wrote: >> I am not against the fact this warning becomes an error per se. I am = just >> not very fan of cherry-picking an individual kind of problem (read: >> notice/warning/error/...) and changing it without a more global = frame. >=20 > I think we should try to hit all of them, ideally in time for PHP 9. >=20 > That was the premise behind: https://externals.io/message/116918 >=20 > It will likely take several RFCs until we've got it in the state we = want it, some of those are more contentious than others (such as = undefined array indexes). >=20 > I think undefined property access should throw too, and will likely = have supermajority support, but let's do it in a separate RFC. >=20 > What I don't think we want is the entire package being blocked because = a particular item (i.e. array keys) is contentious. This is actually exactly what Patrick is complaining about: No global = plan. I know I'm on the "losing" side of this discussion but sometimes it = feels like one of the main arguments is "we already changed this and = that to exceptions, now we have to do it in this case too". Which, to = me, fits the first paragraph of = https://en.wikipedia.org/wiki/Salami_slicing_tactics Maybe we should ask ourselves the question: Why would the entire package = be blocked? Just because it is too big or maybe there *are* subtleties = which have not been properly resolved? - Chris