All, I updated the RFC, and made a couple updates to tests where this notice is raising itself (fpm & mysqli). I ended up catching a couple of oddities in how mine (and previous proposed) changes would have impacted a foreach(list() = each()), so it won't raise a warning on the last, null, element of each.
Before I ask for voting, I do have a best-practices question I hope someone would have an answer to. My dev setup doesn't include all the extensions, nor do I have a copy of windows for testing. What would be the best way to ensure all tests are run so I can find other locations where this warning might be adversely impacting some of the tests? I know Travis will run tests when I create a PR, but I don't know if it is ensuring all tests are fully run either. Thanks -- Dave On Tue, Aug 2, 2016 at 12:33 PM David Walker <d...@mudsite.com> wrote: > Dan, > > You're right on both accounts; also, as I just notices it could easily > have other BC-breaks (although expecting errors in a certain format is odd) > through calls like error_get_last(), which would regardless of INI settings > include this NOTICE. I will update the RFC with these changes. > > -- > Dave > > On Mon, Aug 1, 2016 at 4:27 PM Dan Ackroyd <dan...@basereality.com> wrote: > >> Hi David, >> >> The updated section still doesn't really describe the BC break that well. >> >> Some people will need to change their code to avoid having notices >> raised frequently. How difficult that will be needs to be thought >> about. >> >> Additionally, although the default ini files may turn off notices in >> production environment, I really don't believe that is best practice. >> For my machines, in both production and dev all warnings and notices >> (except deprecation notices in production) are converted into >> exceptions. Anything else allows mistakes in code to go undetected. >> >> cheers >> Dan >> >
