Re: [RFC] Reclassifying engine warnings
| From: | Chase Peeler | Date: | Wed, 28 Aug 2019 18:42:09 +0000 |
| Subject: | Re: [RFC] Reclassifying engine warnings | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-106763@lists.php.net to get a copy of this message | ||
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 –
> > 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).
>
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 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.
>
>
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
>
--
Chase Peeler
chasepeeler@gmail.com