Hi Nikita, This RFC makes me very happy! I have a few points that I didn't find clarification on in the RFC. For "Undefined variable: %s" the new proposal is an Error Exception. For a starter: will it include dynamically declared variables such as $$foo?
For my second point: in regards of backwards compatibility, is it possible to first trigger a deprecation for each of the cases that will abort the flow? If not, I fear I won't be able to upgrade as we still maintain a lot of legacy code that deals with dynamically declared and undefined variables, and possibly other violations that we don't know of. We are working on rewriting all this code but don't have enough developers to rewrite everything under a few years. If we can start logging these deprecations, we know where to fix what, rather than having our entire application crash. This way we can prioritize our maintenance on fixes each of these cases. The scenarios where this occurs often in our code base are dynamically included files that may or may not set a variable. The code is most likely "broken", but the behavior it produces is what's considered correct at this point. It can be solved by defining the variable with null value, but it's hard to trace without logging as we can't always set it with null value. Regards, Lynn van der Berg 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 >
