Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107004
MIME-Version: 1.0
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>
 <31BD63BC-ACE0-4478-B241-E698D2D6F59C@newclarity.net> <CANS-=pexJhtBS=me8RDvg0+BjXWVqmONU4CDVyrGgcsia40YGA@mail.gmail.com>
In-Reply-To: <CANS-=pexJhtBS=me8RDvg0+BjXWVqmONU4CDVyrGgcsia40YGA@mail.gmail.com>
Date: Thu, 12 Sep 2019 20:30:13 +0200
Message-ID: <CAH0Uv3G5xYiPMWNkTt0gRotZVpmL4=j4amFFBOW9UGRm+GWB2g@mail.gmail.com>
To: Lynn <kjarli@gmail.com>
Cc: Mike Schinkel <mike@newclarity.net>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: andreas@dqxtech.net (Andreas Hennings)

Indeed, for the case of local variables that were undefined before,
this can usually be fixed in a straightforward way by initializing to
NULL.
The goal here is to get rid of the error or notice while preserving
the original behavior (even if it was buggy).

This is IF this is your own custom code, or you have a strategy for
maintaining patches on 3rd party code. (which you probably should).

Another problem which has not been talked about much is code like
this, which I have seen in multiple legacy code bases for Drupal 7
projects. Code like this is not considered good practice in Drupal 7,
but it does exist.

  $element['field_category'][LANGUAGE_NONE][0]['#entity']->field_author_lab=
el['en'][0]['value'];

This is crying for "trying to access property of non-object". Because
the values in $element were usually created "elsewhere", and who knows
if the value at that position is an object?

Even worse: This might go unnoticed 99% of the time, but in a specific
edge case the value might not be initialized and the website would
crash with error in PHP8.

The "minimal fix" to preserve behavior 1:1 is to call if (isset()) or
if (!empty()) on the whole thing before every such construct, even if
at the moment you are not aware of cases where it might fail. In the
"else" case, you do whatever would have happened before if the value
was NULL.

On Thu, 12 Sep 2019 at 20:10, Lynn <kjarli@gmail.com> wrote:
>
> On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mike@newclarity.net> wrote=
:
>
> >
> >
> > 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.
> >
> >
> The bug is not that you initialized the variable, it's that you initializ=
ed
> it with a different value: https://3v4l.org/8mB8B
> ```
> var_dump(isset($a));
> $a =3D null;
> var_dump(isset($a));
>
> // gives
> bool(false)
> bool(false)
> ```
>
> Whenever one of these errors will occur, you can initialize either the
> array key or variable with null and it will work again without changing
> behavior. If anything, Wordpress shouldn't be an argument to not improve
> PHP, though I think it's important to consider the impact of a change,
> including for the Wordpress community. However, I think most people agree
> that the quality of Wordpress code and Plugins is highly debatable. I don=
't
> like the idea of not being able to progress because Wordpress users won't
> upgrade PHP.
>
> Regards,
> Lynn van der Berg