Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106997
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> <CAAwbVufSPH=YjZZO5y4gzROS1e-ok+rpYrrBvGO-=DOnvtCKSw@mail.gmail.com>
In-Reply-To: <CAAwbVufSPH=YjZZO5y4gzROS1e-ok+rpYrrBvGO-=DOnvtCKSw@mail.gmail.com>
Date: Thu, 12 Sep 2019 14:09:39 -0400
Message-ID: <CAPKYkKyi5yTSRCmO7vP8Aqv-9jFEgear8iBDUs+ShpP=3h=31g@mail.gmail.com>
To: Olumide Samson <oludonsexy@gmail.com>
Cc: Mike Schinkel <mike@newclarity.net>, Lynn <kjarli@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002c6dee05925f0b35"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000002c6dee05925f0b35
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 12, 2019 at 2:07 PM Olumide Samson <oludonsexy@gmail.com> wrote=
:

> I think it would do this list more good than not, if we talk or assume
> about some people who will ever or never upgrade...
> Seriously?
> How do you know if they would never or ever upgrade, you can only and
> should probably speak for yourself...
>
> If they want more customers(translating to revenue), they can upgrade and
> if they don't it's all up to them...
>
> On Thu, Sep 12, 2019 at 6:59 PM Mike Schinkel <mike@newclarity.net> wrote=
:
>
> > > On Sep 12, 2019, at 10:37 AM, Lynn <kjarli@gmail.com> wrote:
> > >
> > > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepeeler@gmail.com>
> > wrote:
> > >
> > >> There are valid reasons for not always initializing variables or arr=
ay
> > >> keys. It might be a bad
> > >> reason in your opinion, but others view it as perfectly acceptable.
> > >>
> > >
> > > 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 o=
r
> > not
> > > people should initialize variables is debatable from a programming
> > > perspective. From a reader's perspective it's really important to hav=
e
> > > variables initialized with a default value, even if it's just null, t=
o
> > > prevent missing certain assignment branches and avoid bugs. From 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.
> > >
> > > 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 cod=
e
> > 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.
> > >
> > > 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.
> >
> I think they could switch to using null instead, or perhaps get something
> else to differentiate what they have initialized or not, that shouldn't
> stop them from using PHP, probably it will only make them not upgrade to
> PHP if they think their bad coding practice is the way forward and the be=
st
> way to code..
>
>
Can you please stop speaking for what you think they should do? Only they
can speak for what they should do.


> 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 upgrad=
e
> to
> > PHP 8.  Probably ever.
> >
> > This is merely assumptions and you can't speak for companies you don't
> know, what's the statistics backing these your use of "ever and never"?
>
>
> > BTW, prior to gaining this company as a client, the internal people fel=
t
> > 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 thei=
r
> > case, we will be cleaning up the code base (although doing so will be
> very
> > costly for them.)
> >
> > And I estimate there are a large number of similar scenarios in the wil=
d
> > that do not currently have plans the people or the funds to clean up
> their
> > similar code.
> >
> > It's up to them, PHP 7 is still available and will always be available
> for
> them to use...
>
>
Yes, but, there are going to be other features in PHP 8 that won't break
existing code and are beneficial. They may be forced to stick with PHP 7,
but don't act like that is a perfectly acceptable option without any
downsides.


> > #jmtcw
> >
> > -Mike
> >
> >
>


--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000002c6dee05925f0b35--