Re: [RFC] Reclassifying engine warnings

This argument makes sense for arrays and objects (and I don't promote > undefined index/property to exceptions for that reason), but I don't think > it holds any water for simple variables. Writing @$counts[$key]++ is a lazy > way to count values and avoid ugly boilerplate for if > (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }. > But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1. > Outside of variable variables, the concept of a conditionally defined > variable just doesn't make a lot of sense. > The variables are not conditionally declared on purpose, but as it's code written 15~20 years ago, maintained, copy-pasted over and over and never reviewed, there's a lot of issues that remain that my trigger an error exception if this proposal is passed without migration path. ``` // a.php if ($someCondition) { // comes from another file, never used, can't verify existance $foo = 'foo'; } // b.php $bar = 'bar'; // scenario1.php include 'a.php'; // this would crash include 'b.php'; echo $foo . $bar; // this would crash if the include didn't yet // scenario2.php $someCondition = true; include 'a.php'; // this would not crash include 'b.php'; echo $foo . $bar; // this would not crash ``` The problem with the above legacy code, which we sadly have spread through a spaghetti of thousands of files, is that if it starts throwing errors with no migration path, we simply can't update without spending possibly weeks debugging and trying to find scenarios where this might trigger. Now I'm not sure, but if I would've used include_once and combine this with function/class scopes (people loved to do that in our legacy code), all hell breaks loose and it will be nearly impossible to find the cases. All I'm asking is for a clear upgrade path with deprecations so that my code can be safely migrated over time, rather than have it crash with the next version. Compared to <?php vs <?, this will break a lot and is not as easy to fix. By having it throw deprecations which we can easily log to a specific file, we can gather and fix the cases when we have time to spend on technical debt, and by the time the warning will turn into an error exception, we'll have fixed probably 90%+ of the cases, making the upgrade possible. Regards, Lynn van der Berg