Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106761
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=lmJC0hBg+AwIWUW7LBtUV/fYAALQo64DX1DyoGI3e/Qsq9hjSHlD7xS3WAjpca
	dLr/aCZw6pIb3TsG7ANyxtO/3eyQNVCID/MX9DHmGl5UoN/FvdjxPLln8IxVicJu
	wLZKaKxwbBq4R4cxJdjbUORwZDLoUWRop04LHAeQ9ILoY=;
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com> <CAKuGYLQC2z+GmOgbqxFWbAGS6B2z=mXTp72c6Be53ju4D6pNRw@mail.gmail.com> <CAJHtznxgkUFZ2os5Hx5rYmFCrATJ+LTOovK6W4J1cDw6oo45=w@mail.gmail.com> <CAKuGYLQfg8CQOORWTO57Cfk92oM3DNmw0h9wt3jP9gSUCx+QWg@mail.gmail.com>
In-Reply-To: <CAKuGYLQfg8CQOORWTO57Cfk92oM3DNmw0h9wt3jP9gSUCx+QWg@mail.gmail.com>
Date: Wed, 28 Aug 2019 21:31:55 +0300
Message-ID: <CAJHtznw1POVOtK656fWn+Vdj94RnHWmZ9A5rEHoWjiXXod=Piw@mail.gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000316a4b0591319b53"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: zeev@php.net (Zeev Suraski)

--000000000000316a4b0591319b53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> We log 1 in every 1000 notices, and yes - being notice-free is a goal =E2=
=80=93
> though not one with any particular timeline at the moment, because we can
> just ignore the problem. I look forward to not being able to ignore the
> problem.


When was this goal set?  Was there effort that went into it?

My point is this:

In a codebase where being notice-free isn't a goal - and/or where code
patterns that rely on the documented behavior of how PHP variables are
initialized as well as behave in read scenarios (with or without the
silence operator) - I think you're going to find a lot of such instances,
probably more so than in a company that made an informed decision to not
allow it and gradually work to remove existing code that uses it.  For
many, this is not considered technical debt - but rather - using the
language *as intended*.  Using the language in a way that is sanctioned and
considered valid - alongside other ways which are also considered valid
(e.g. a notice-free codebase).

While I understand what you're saying when you say that you look forward to
not being able to ignore the problem, it sounds like a fairly weak argument
for forcing everyone else - many of whom don't consider this to be a
problem at all - to change their code.  Instead, if this bothers you, make
an informed decision to change - there's enough tooling to do that today
with reasonable effort.  Or support the ability to flip a switch that will
granularly force you to fix these particular issues.  Forcing all users to
work in a certain way, because some of the users who want to work that way
can't bring themselves to do it - doesn't sound very sensible IMHO.

I was hoping that the glaring obviousness of how other languages tackled
similar issues (Perl, JS) would go a longer way.  It should.

Zeev

--000000000000316a4b0591319b53--