2015-03-11 6:27 GMT-03:00 Lester Caine <les...@lsces.co.uk>: > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote: > >>> BTW, the current PHP silent behavior should be considered even more > >>> > > confusing otherwise we > >>> > > wouldn't have these measurements: > >>> > > > >>> > > > https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world > >> > > >> > I'm not sure how these prove current behavior is "confusing". Yes, > there > >> > are bugs in the code, and I'm sure this feature will expose some of > >> > those (previously harmless) bugs. At cost of the BC break. And don't > >> > think a handful of libraries represent the vast universe of PHP code, > >> > most of which we can't even see because it's not published anywhere. > > What do you mean here? > > > > Again, introducing a warning isn't a real BC-break and as you says there > are > > bugs it helps nobody ignoring them. If you think so you can do that with > all of > > your own bugs by ignoring warnings/notices. > > I must say I was a little confused when I first saw this given the > number of errors I got when addressing the E_STRICT ones on existing > code. One ended up creating multiple functions with different arguments > to get a clean set of code, but I had perhaps not even realised that > adding extra arguments was not flagged.
A lot of people don't know it too, and they are shooting themselves on the foot without realizing it because PHP is currently silent about it. > In practice my IDE setup is > flagging warnings where variables are not used, and it seems that > perhaps I'm in a 'safe place' because of the whole package rather than a > particular 'bug' in PHP. > > Your IDE is a tool you are using to be safe from the current PHP misleading behavior. It's fine to use tooling, but that's a basic feature that shouldn't require special tooling. > Most of the examples being shown are examples of simple bad programming > practice that needs fixing anyway, and I would expect a proper code > review to have picked them up, so don't see that adding the check in PHP > is essential. It would however be a useful addition but in the E_STRICT > category ... not that I want to maintain that, but being able to ignore > those errors until such time as it is appropriate to fix them. I think this is a valid argument to keep the E_STRICT error level option for the secondary voting. That's a very useful information, thanks :) > The > poorly checked code is the problem rather than PHP here, and I'm with > Stas that it's probably being a bit heavy handed at this point in the > PHP7 process. Actually I would be rather annoyed if the problems > demonstrated have not already been cleaned up already? The examples are not "poorly checked" code, they were retrieved on widely used packages we all rely, directly or indirectly. Both code and tests used in the measurements are maintained by experienced people and yet the problems found a way to lurk (it's not a fault on the maintainers side). I'd say it's enough information to improve the language, not to require that people should manually check their code more or use tool A or B. > A tool to > identify problems and get them cleaned before the main test is switched > on helps everybody? > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Thanks, Márcio
