Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119113
MIME-Version: 1.0
References: <CAMXcktOiFH-0f0PG9cKkkVaczjNLSzQzzPUBcoLyn54X=c74og@mail.gmail.com>
 <D494A14E-0733-406B-844E-DD2D3FBB7EB4@php.net> <5fe0d8a9-d305-9c9d-ca36-1ca30de87b78@cubiclesoft.com>
In-Reply-To: <5fe0d8a9-d305-9c9d-ca36-1ca30de87b78@cubiclesoft.com>
Date: Tue, 13 Dec 2022 11:01:48 +0100
Message-ID: <CAPzBOBMpQimOxz9f1ABoKtLeUzKqV=-yHHOmYk-HHp-GY52MRg@mail.gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
From: landers.robert@gmail.com (Robert Landers)

On Tue, Dec 13, 2022 at 12:36 AM Thomas Hruska <thruska@cubiclesoft.com> wr=
ote:
>
> On 12/12/2022 3:52 PM, Derick Rethans wrote:
> > On 12 December 2022 22:20:27 GMT, Dan Liebner <dliebner@gmail.com> wrot=
e:
> >
> >> 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_WARNI=
NG
> 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=C2=A2 on the matter.

Robert Landers
Software Engineer
Utrecht NL