Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106741
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAJHtznyadHb5_RgjddnPiyeWXtLQyp2CDK=ix=BiEd+DEUHqLg@mail.gmail.com>
 <CAF+90c_94zAj-7XW+=YtZ2VsZEshd4DvNY8_17PyiBXvYR1gdw@mail.gmail.com>
 <CAJHtznw5wOTMA-BUO6hOARxSie75+PwccSocVapHi4k02Z+x0A@mail.gmail.com>
 <CAPKYkKzc37d52ZjHy0ht6Oc_HgoBq4+DandNW1Hk-+x5NnUS7Q@mail.gmail.com>
 <CAPKYkKwhUmq40yGta3+ERfcDOOrkPi5Db6-i7pPMRmV4CrQRTQ@mail.gmail.com>
 <7ddbae5c-7451-4094-8b32-19676128054b@thelounge.net> <CAPKYkKyYvqW9Hm-nae0CXJ98XxRzt7XRpe_+FzeqiJME3K4jug@mail.gmail.com>
 <CAPKYkKw5vxgeM+vq_z9YhNYEMuPodCjfGNv6BRFS+bg0BG-Q0w@mail.gmail.com>
 <CAOkcCt_xsP1AOwB0-nuY4_qwxSc3h8mns_Yax9UnrLzFCN-m+g@mail.gmail.com>
 <CAPKYkKxAkowF_H9gDZg2pDVdUyftJz0b2LAE08jW8jjA6Nq-uw@mail.gmail.com>
 <CADyq6sJd6=2UEXXrad2heYw4Mp876rSQ9ZcKeuXOKEWO8F2saA@mail.gmail.com> <CAPKYkKw7Q7A4Z5TkgNX-=LPZZy7_orCRUsULBA7j=wZgKU-VuQ@mail.gmail.com>
In-Reply-To: <CAPKYkKw7Q7A4Z5TkgNX-=LPZZy7_orCRUsULBA7j=wZgKU-VuQ@mail.gmail.com>
Date: Wed, 28 Aug 2019 18:36:51 +0300
Message-ID: <CAJW__o19_rchtPgdC5mAKGvLpemjdy8uJP_BJ6Xq9Ctbs0C_7g@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Gert <gertp93@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: kalle@php.net (Kalle Sommer Nielsen)

Hi

Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler <chasepeeler@gmail.com>:
> You going to come and fix the issues? It's an internal application and
> most of those messages are coming from legacy areas of the code which are
> mainly "it works, so leave it alone" things. Instead of going back and
> spending time trying to fix those boondoggles, we invest the time of our
> developers (there are 2 others besides myself) into building new features
> that help our business grow. Time permitting, we try and update some of the
> legacy areas, but, we usually find it's a better investment to just rebuild
> them at that point.
>
> Bottom line is that we live with the not-so-good stuff so that we can focus
> on adding new great stuff. The not-so-good stuff isn't holding us back, and
> trying to fix things like undeclared variables would have absolutely ZERO
> positive effect on our business, which uses this application every day. If
> I went to our executive team and said "Can we delay that new scheduling
> system that will really help our business so I can go back and update code
> to get rid of these undeclared variable notices?" I'd get laughed at!
>
> Like I've said before - can we please stop pretending we understand
> everyone else's situation? Maybe my situation is unique. My gut tells me it
> might be unique among people on this list, but, that it's actually pretty
> common among the myriad of developers out there which never get involved in
> these discussions.

I'm sorry, but like Mark Randall has already pointed out then this is
a classic example of technical depth. At one point you must choose,
"Do I want to upgrade to the latest version of PHP or do I want to fix
the issues which is caused by the technical depth in my stack?". I get
it, writing new code is always more fun, it really is, I have
previously worked with companies with that same attitude that "we'll
fix it later", but at one point that becomes such a burden and if your
management doesn't believe in putting in resources to actual
maintenance of your infrastructure, then I'm sorry but it does not
sound like a healthy place to be (no offense meant).

Right now your argument is merely trying to hold back changes which
will bite that technical depth of yours, and everytime an argument has
been raised towards your concerns it has been met with "Will you come
and fix it?", "I demand that X, Y or Z tool is available for me to
use", etc., so again, I'm sorry but I'm not buying this argument.

Some things we can solve by an opt-in, like the strict_types declare,
however other things so fundamental to the language should not have
any options to alter its behavior, that should be consistent. We have
spend a long time trying to carve a migration path and advocate
against options which changes language behavior across installations.
If we continue down this path, then its just a runtime version of
php.ini with a million declare statements on top of each file, each
having multiple meanings and an added complexity to maintain the code,
not a burden I think userland developers need as it is.

--
regards,

Kalle Sommer Nielsen
kalle@php.net