Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119123 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 73398 invoked from network); 13 Dec 2022 14:32:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Dec 2022 14:32:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 44C1A180545 for ; Tue, 13 Dec 2022 06:32:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8560 212.227.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 13 Dec 2022 06:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1670941976; bh=D9s1AhhFezMmt4rI3HZ0aXKeXin4SIJiHzBV1sibkLE=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=SyLwgQKlyCK/jo49HWGHu1M2uW8R/duQzrPa7/WbGZefyRbm5k/732f2p8S2xWM2K sCpibh70qDChqPuC0K2DRTPhQGNrGUaQphIhmkfuBhDYxoBjUEdtuEuRbmqOe2kW51 6kRfQgXjG9iUt9IDBTGYEhAZck2MW0qHrMD9m/oHILpG9iLOjDdu+cqkgSMGG5HRuD Wm+1I5ery2Ewxx6fKuzp31fsagJY9jnOEEUyFNGB/GAilbkT4bsTslQf8GamSUayf7 odpIA7/1FbA2fPivBoCEU99/M1tkRjVI/WV/i6VckAk/6wtV+h7R0dqOTuMz1DtzHD MQgvnVChsX+cg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.120] ([24.134.51.41]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MoO24-1oY0eF3XU8-00opET for ; Tue, 13 Dec 2022 15:32:55 +0100 Message-ID: <4637768a-70c3-83ba-166e-9a9f5ba61c16@gmx.net> Date: Tue, 13 Dec 2022 15:32:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Content-Language: en-US To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:OHyn3vY4VKZex3kr5Tuei15zf5DAP7kKPUV8zBbYZH6OlonuKml 8f6DFcedbcKs51ImLhgjJTRPQI0RxXBjQY9KskkJznPbP8RdMGJ+T0nAIIiuG/kDsb0ZIHG WG1X4ILl2ZpPe1sVYjGXER0YEvhpURxbcMEvMKuZ/fGr8chBf4s8FpzuQ2UhZzDnMGS4Zb9 Tyo9RHiAGuHXfKjaED3Aw== UI-OutboundReport: notjunk:1;M01:P0:q5FZMAxM1eA=;VEkjxiVftW/WVuxw81qtT09SJpw GusLI8VClOMfM8UUJSIBhI6y/H6yads184nVtoqDhA1ydMPKGgBl9nEL5Y0zwLtp9v36YvGQS JWk58Af9DgahqPuTQ/XGu54eCSImgnPlLqygbgeozs1aVGJ7F+Zs9dQhKpv52QtbAQkTik9k4 MBDf0hmGOCmqRig42uz7X3y4aZyGg+dQy7zX0rDjAb64C/X6bZGfEL+vqaGQt8ruaTYYe19Jf A6Qet4iW+EwY6c5V1y/nCs7cHxJwV/2rgUtSoCSF6APoU2zExuq/DhoXDXQJzoTDuI4S0M7Mr GN4ui70kQaexsQqphqDMlU+hulo1x9IrWyKRZGv4tPvDM8IREMC2KvD+//fUpbU7pmfcSn1FZ r2zQCUOlaZiRaPBgy1S/HUX+4IKNg6sRq2+t+L5xskEcvalYRSevOtD3Gha+EkLsNhtWtNMMh k7liAp9lo4US0DPuIuo7oadD12oR1lBSD/k+Y2F1W2ri5CbTTdFvm+S5xyQZ1mZQ0bKpJW9+x +ZNOVVi6pBaAoCaqDY6kAAs5ZIV4Drkdy58PbJhKoEOgrENH668SloL73dVBvU7EqYizscoto 6NAZhexKcSxtJuwA48duyS0Er94206R7S7QKZeDSO5u1r7VjMZHg8ssmSIoLaKurP9f444mwe OBktcLRFk6XMvMTLojZJIdIUNRjUFXtDiON+RoHU5OgVRhGZOdMWedXppdiX5wMKOwBz79ax8 cDtfNN+QxSIKKny/skRYpW0SsBUZv4XGuS8rg+0nFfv+ArtaiPYQr9Zp5A++Eo0bDuaejAXAX jl3FlOR7MRBmUUfCTehLJauo454DQ+c9HUWM+i8VEsnTYnyF6d18/aGqVQJsXHsWs4cLCBhRb JZDkSfhxQsDL+UN0HpncJLXajsLUzmkJ551AtQ/7MdNR9pyx4jIE2Bavz24Kz2ikBl1VBFNSU zFzd/g== Subject: Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index From: a.leathley@gmx.net (Andreas Leathley) On 13.12.22 13:53, Dan Liebner wrote: > It breaks my app. Does that count? This sounds like you completely ignore notices in your application yet elevate warnings to exceptions/errors. It would be better to log both notices and warnings without generating exceptions/errors, and look through those logs from time to time, to see possible issues (and nothing would currently break that way). I used to suppress notices in my applications too, but after logging them it was my experience that notices can usually be easily avoided and often hint at oversights / possible improvements. > Here's another suggestion: > Make accesses to undefined array keys (objects, variables, etc) return a > new `undefined` primitive. That way, developers who are focused on writi= ng > concise, readable code can continue to write and maintain code manageabl= y, > and developers who are keen on writing a lot of code in a more "strict" > manner can handle undefined array key accesses consistently, without hav= ing > to rely on configuration settings. That would likely be a major change and break in the language (which is usually frowned upon), but if you have a clear concept, you can create an RFC for it and start a discussion. I do think that your view on "concise, readable code" would in my mind be code which is more prone to bugs and unclear in its intentions. If an array index possibly does not exist and you check its value, it would already be unclear to me if you mean to check for its existence, or for a null value, or for a non-empty string, or something else. Making it clear the index might not exist gives a reader more information, and making the expected types (and checks) clearer in general is not an exercise to be strict for fun, but to avoid bugs because of unexpected values.