Re: [RFC] Reclassifying engine warnings

From: Date: Wed, 28 Aug 2019 14:24:33 +0000
Subject: Re: [RFC] Reclassifying engine warnings
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-106731@lists.php.net to get a copy of this message
On 28/08/2019 14:48, Chase Peeler wrote:
My position is that this should be done as an opt-in feature like Zeev as proposed. If it is not done as an opt-in feature, then I don't think it should be done at all.
IMO one shouldn't have to opt-in to use common-sense error checking of engine operations. It's essential to think of the long-term future of PHP and what makes sense going forward, and to my mind that means things need to be more intuitive and less prone to mistakes. Be it Little Jonny Just-Grad who is starting his first proper PHP project, or the lead engineer of Megacorp, Inc. who is about to write the first line of the company's next multi-million dollar hit, they shouldn't need to pile-up on declares at the top of each page just to make the engine perform as intuitive common sense would dictate. By the very nature of using @ to suppress error messages, the examples given are all fully aware that the behaviour they are using is not good practice. If the engine was perfectly confident in your use of the statements that followed it, then it wouldn't display an error that you would need to suppress in the first place, now would it? Besides, we have tools available for years now to make this behaviour more defined: $counts[$key] = ($counts[$key] ?? 0) + 1; "If $counts[$key] is not set, use the value 0". Null Coalescing was explicitly designed to provide for this behaviour. -- Mark Randall

« previous php.internals (#106731) next »