On Thu, Sep 12, 2019 at 9:40 AM Claude Pache <claude.pa...@gmail.com> wrote:
> > Le 10 sept. 2019 à 15:31, Nikita Popov <nikita....@gmail.com> a écrit : > > > > On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov <nikita....@gmail.com> > wrote: > > > >> Hi internals, > >> > >> I think it's time to take a look at our existing warnings & notices in > the > >> engine, and think about whether their current classification is still > >> appropriate. Error conditions like "undefined variable" only generating > a > >> notice is really quite mind-boggling. > >> > >> I've prepared an RFC with some suggested classifications, though there's > >> room for bikeshedding here... > >> > >> https://wiki.php.net/rfc/engine_warnings > >> > >> Regards, > >> Nikita > >> > > > > Heads up: This RFC may go to vote tomorrow. > > > > Nikita > > > I have objections to those two reclassifications: > > * Undefined offset: %d — Notice → Warning > * Undefined index: %d — Notice → Warning > > > From experience, having to dutifully initialise each and every key in an > array is burdensome. I understand the rationale of enforcing that in some > coding standard; but whether those particular missing index should be > considered as unexpected (therefore deserving a Warning) is mostly a > question of coding style. > > This is in principle a similar issue as using uninitialised variables, > which, as noted in this thread, is a perfectly accepted coding pattern in > some languages (the issue being distinct from *undeclared* variables). I > say “in principle”, because a perfectly reasonable coding style may choose > to enforce initialisation of variables, but not of array keys. > > PHP has the advantage of supporting various coding styles. We should give > the opportunity to the users to say declaratively (and precisely) what, in > their coding style, is considered as acceptable, e.g. > > declare( > uninitialized_variables: error > uninitilalized_index: none > ); > > of course, possibly at a package-level declare. That would, for example, > enable people to place legacy code in lax mode and chose a stricter mode > for new code, even letting the precise notion of strictness vary with > fashion without having to review working code written two years ago. > > That said, as long as those issues are handled as errors (as in: > set_error_handler()) rather than exceptions, one may write a proper error > handler that does the distinction (I do that). However, an error handler > has the disadvantage of being global, making difficult the integration of > code written with differing coding standards. > > —Claude > Hi Claude, I have split off the question of undefined array keys into a separate section, which will be voted separately. I generally agree that ignoring undefined array key notices can be a legitimate coding style choice (while I would very much disagree that the same is true for undefined variables) -- though ultimately I think it is best to handle this with a custom error handler (which can check whether the error originated from your own codebase), rather than through a blanket suppression of notices. In line with that thinking I don't think it matters overly much whether it's a notice or warning for the purposes of suppression. But I also don't feel particularly strongly about having this case as a warning either, especially with the error_reporting=E_ALL default in PHP 8. Nikita
