Am 28.08.2019 um 13:10 schrieb Nikita Popov <nikita....@gmail.com>:
> On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski <z...@php.net> wrote:
>> 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.
We often use the pattern $a .= "xy" or $a[] = "xy" and requiring to initialise
leads to either boiler-plate code in often very simple functions or even worse
to write the first one as $a = "xy" and $a = ["xy"] which both hurt symmetry
and extensibility (you need to change two places if you want to add a new first
entry). We are already suppressing the E_NOTICE for this as the pattern is too
useful to fill our logs.
Your simple typo in variable names can be caught well enough by a static
analyser, we have a simplistic one in out git commit hook which more than does
the job for us. And it does it even better in your average case as it also
catches typos in rare code paths not executed by your tests. And no, don't say
"make sure you have 100% code coverage", that is a myth.
Summary: Promote E_NOTICE to E_WARNINGS, fine, make them abort code execution:
Don't do it, don't break our code.
For people promoting a stricter PHP mode: Just fix your code if it caused an
E_NOTICE/E_WARNING, you don't need an Exception for that. And I don't buy the
whole security argument, code has to be secure on a whole different level than
undefined variables.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
