On Tue, Dec 13, 2022 at 12:36 AM Thomas Hruska <thru...@cubiclesoft.com> wrote: > > On 12/12/2022 3:52 PM, Derick Rethans wrote: > > On 12 December 2022 22:20:27 GMT, Dan Liebner <dlieb...@gmail.com> wrote: > > > >> It has been proposed to make the error level of "Undefined index" > >> configurable so that teams and individual developers can decide for > >> themselves how they want this situation to be handled. Given that: > >> > >> - PHP has been treating this as an E_NOTICE for over 20 years > > > > But not in the last three years. > > PHP 8.x is only starting to roll out in Linux LTS distro packages at the > end-user level. I've moved to 8.x internally but I am, in particular, > waiting for Ubuntu Server 22.04.2 to officially drop before beginning > meticulously planned upgrades to mission critical systems. I suspect > many people are in a similar holding pattern who are currently running > packaged 7.4.x and are just now discovering all of the changes for PHP > 8.x as they are planning out their system upgrade paths in the coming > months. While you probably wish everyone marched in step with > PHP-latest, that's simply not feasible in reality. > > The type of post that the OP sent to internals is likely to become more > common in the next few months as PHP 8.x starts rolling out globally. > Most businesses are waiting for at least the holidays to conclude before > performing any major system upgrades if not longer for specific OS > releases to drop. > > -- > Thomas Hruska > CubicleSoft President > > CubicleSoft has over 80 original open source projects and counting. > Plus a couple of commercial/retail products. > > What software are you looking to build? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
Hello all, > The recent change to elevating "Undefined index" from E_NOTICE to E_WARNING > set forth and passed by https://wiki.php.net/rfc/engine_warnings to me > seems antithetical to what PHP has been and what has made it a choice for > developers over the last few decades. >From my perspective, in the last few years, it seems that PHP has been trending towards "preventing dev mistakes" over anything else. IMHO, this has prevented us from getting some really nice language features, such as operator overloading (because "devs might make mistakes"). I think it is worth pointing out that PHP has always had this kind of interesting dichotomy towards letting devs do what they want and preventing them from doing 'bad' things. For example, even though you could divide by zero you could never create a socket with AF_PACKET and send raw IP packets from PHP. Is this a bad thing? I don't know, but it's interesting to watch the language evolve and so far the changes have revealed hidden bugs in existing code bases, at least in my experience. However, fixing those bugs has been a nightmare because some of them have been there for 10-15 years. Ancient silent bugs are suddenly showing up and you have to make a hard call on whether to fix the ancient mistake or keep the broken behavior. It isn't always a simple decision and may often be a business decision vs. a technical one. Interestingly, with the array access warning, you now have to write much more boilerplate code just to do something that was once the default behavior. Not only does this require much more typing, but it also introduces much more cognitive load as you have to figure out whether a key has been set before (or be defensive, which introduces potential performance implications). Even then, using ?? on array access can introduce more bugs than it is meant to prevent. Most devs find out the hard way that ?? has an unintuitive order of operations: typed: $a['foo'] ?? null || $a['bar'] ?? null intended: ($a['foo'] ?? null) || ($a['bar'] ?? null) Further, writing code like this increases the number of opcodes needed to perform relatively simple logic by ~150%, increasing end-user latency and spending CPU cycles somewhat needlessly. Personally, I'm a fan of some of the changes made to the language, and I look forward to PHP's future. I hope this "preventing dev mistake" mindset is just a phase though because, IMHO, it really has held back some fantastic proposals that people put a lot of time and effort into. It's also caused us to have to write much more boilerplate code for a debatable benefit. Anyway, as an outside observer, that's my 2ยข on the matter. Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
