Re: [RFC] Reclassifying engine warnings

From: 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

« previous php.internals (#106763) next »