Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106994
Message-ID: <31BD63BC-ACE0-4478-B241-E698D2D6F59C@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_35C53316-8856-4356-90E8-084A08D5A90F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Sep 2019 10:58:58 -0700
In-Reply-To: <CANS-=pc7Av0+jSKNebb-iae+BpTt6_72kRSHSowb-hon4rxUgQ@mail.gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
To: Lynn <kjarli@gmail.com>
References: <076701d56978$86020910$92061b30$@php.net>
 <CADyq6sK4HektgfDpCCFR3=bumyPaf9vn=-WdvaboHybBQKd53g@mail.gmail.com>
 <078e01d5697c$5512bc10$ff383430$@php.net>
 <CAKws9z1EBSqCFy2wD3cEV49KDSJOd6tT04PrCkxG8+3Hb6WpTA@mail.gmail.com>
 <CAPKYkKw1EU3Qp6W7b19r4kMKPD1HntH+7NQSxSiDNcLXqPERMA@mail.gmail.com>
 <CAKuGYLRWF9jnS-Zs+uRFNN1pgRSvHFpW-FChgNq9Rk282AFFGA@mail.gmail.com>
 <CAPKYkKxUyeWWZY5OyDLtAYiDUYLkwyMjuc_Wq2Y++3C9CP6G1w@mail.gmail.com>
 <CANS-=pc7Av0+jSKNebb-iae+BpTt6_72kRSHSowb-hon4rxUgQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_35C53316-8856-4356-90E8-084A08D5A90F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Sep 12, 2019, at 10:37 AM, Lynn <kjarli@gmail.com> wrote:
>=20
> On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepeeler@gmail.com> =
wrote:
>=20
>> There are valid reasons for not always initializing variables or =
array
>> keys. It might be a bad
>> reason in your opinion, but others view it as perfectly acceptable.
>>=20
>=20
> I recently had to fix a bug where a variable was renamed, caused a =
merge
> conflict and resulted in months long of changing a business process =
with a
> subtle bug, as null was not the intended initialized value. Whether or =
not
> people should initialize variables is debatable from a programming
> perspective. =46rom a reader's perspective it's really important to =
have
> variables initialized with a default value, even if it's just null, to
> prevent missing certain assignment branches and avoid bugs. =46rom my
> perspective, this should've thrown an error, so we would've fixed it =
the
> same day. Now PHP simply broke our business process for months.
>=20
> Yes, we hide notices, even in production as our logging server would =
die
> within a minute if we'd turn it on. Yes, this is a massive legacy code =
base
> where lots of tests are lacking. Can we change this? Sure, will take =
years
> though. Would we have benefited from PHP throwing an error in this =
case?
> Most certainly, would've saved us a lot of headache, and money.
>=20
> You argue that it's a fundamental language change, I -and seemingly a =
lot
> of others- argue that this is more of a bug fix.

Just a few weeks ago I was refactoring some particularly horrible code =
developed by previously employed developers =E2=80=94 a code based that =
has a 1400 line function and many other functions 100s of lines long, =
and I added some initialization for variable and array elements prior to =
their use.

Unfortunately my changes broke the code because the original developer =
using isset($var) as branching criteria.  After finding this bug, I =
realized that this code base uses that technique frequently.  I am know =
from lots of experience that this is a common technical among WordPress =
plugins.

If PHP8 were to change to require variables and/or array elements to be =
initialized then this code base and any similar to it will be broken. =
Companies with these code bases almost certainly will simply not upgrade =
to PHP 8.  Probably ever.

BTW, prior to gaining this company as a client, the internal people felt =
that the codebase needed to be completely rewritten rather than =
incrementally refactored. And because rewriting would have been such a =
large project they have been putting it off for several years.  In their =
case, we will be cleaning up the code base (although doing so will be =
very costly for them.)=20

And I estimate there are a large number of similar scenarios in the wild =
that do not currently have plans the people or the funds to clean up =
their similar code.

#jmtcw

-Mike


--Apple-Mail=_35C53316-8856-4356-90E8-084A08D5A90F--