Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106763
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> <CAJHtznw1POVOtK656fWn+Vdj94RnHWmZ9A5rEHoWjiXXod=Piw@mail.gmail.com>
In-Reply-To: <CAJHtznw1POVOtK656fWn+Vdj94RnHWmZ9A5rEHoWjiXXod=Piw@mail.gmail.com>
Date: Wed, 28 Aug 2019 14:42:09 -0400
Message-ID: <CAPKYkKwwt5UiCqz+KX+M-qMaYJL8vk0LAkU+isfXrUAQggPZpQ@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Matthew Brown <matthewmatthew@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d58306059131bfeb"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000d58306059131bfeb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 28, 2019 at 2:32 PM Zeev Suraski <zeev@php.net> wrote:

> 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 c=
an
> > 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 a=
nd
> considered valid - alongside other ways which are also considered valid
> (e.g. a notice-free codebase).
>

For the record, I don't view undeclared variable notices as technical debt
either. I've engaged in that discussion at other points because I think
this is a bad move even if it is considered technical debt. My personal
opinion is that I like the flexibility of the language in this matter. I
initialize my variables most of the time anyway, but, I don't think every
other PHP developer should be forced to do that just because I like to do
it.


>
> 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 argume=
nt
> 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, mak=
e
> 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 wil=
l
> granularly force you to fix these particular issues.  Forcing all users t=
o
> work in a certain way, because some of the users who want to work that wa=
y
> can't bring themselves to do it - doesn't sound very sensible IMHO.
>
>
My feelings exactly. What benefits are we getting by FORCING everyone to
follow this policy that individual users/companies/development teams can't
already gain by just making it a policy and using 3rd party tools to
enforce it? What HARM continues to exist in the language if undeclared
variables only generate a notice - given the fact that how PHP handles
undeclared variables is will documented and, in my opinion, actually a
feature of the language?


> I was hoping that the glaring obviousness of how other languages tackled
> similar issues (Perl, JS) would go a longer way.  It should.
>
> Zeev
>


--=20
Chase Peeler
chasepeeler@gmail.com

--000000000000d58306059131bfeb--