On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski <z...@php.net> wrote:
>
>
> On Wed, Aug 28, 2019 at 12:33 PM 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
>
>
> Specifically on undefined variables, the way we deal with them has little
> to do with register_globals. It's behavior you can find in other dynamic
> languages (e.g. Perl), and allows for certain code patterns (which rely on
> the automatic creation of a variable whenever it's used in write context,
> and on a default known-in-advance value in case it's used in a read
> context). It's fine not to like this behavior or the code patterns that
> commonly rely on it (e.g., @$foo++), but it's intentional and isn't related
> to any historical reasons.
>
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.
> I think many (if not all) of your proposals make sense, but most of them
> make sense as an opt-in - perhaps using something similar to Perl's strict
> mode (which incidentally, changes the way the language treats undefined
> variables in exactly the same way). This would also provide a future-proof
> solution for additional similarly-themed proposals (such as strict ops,
> etc.).
>
I don't think this is an appropriate use of an opt-in. It's a case where we
can balance language cleanup with backwards compatibility concerns. Code
that works after this proposal will also work before it, and as such there
is no danger of ecosystem bifurcation that would need to be addressed by an
opt-in.
Thanks,
Nikita
