Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88261
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <61163E50-AF39-4F69-B740-7F2D40129DB1@thesba.com>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com> <1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@craigfrancis.co.uk> <55E5EBBF.6020803@gmail.com> <0BA3A129-D356-4781-B6DE-E2B5A7924AE2@craigfrancis.co.uk> <55E6EC36.6090301@gmail.com> <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk> <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com> <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk> <55F07BA4.2000204@gmail.com> <E8634CF1-C2B4-4C5A-8DDC-531D9599774B@craigfrancis.co.uk> <55F6B911.9080400@gmail.com> <96BE7F01-D04B-483B-B1A3-B45CED6DFCDC@craigfrancis.co.uk> <55F6F08C.1020506@gmail.com> <0BEF6D82-CB5F-49F6-A3A4-3267924A0CDA@thesba.com> <55F72CA9.2060301@gmail.com> <09369945-76FE-4E08-9C2C-15FB0577AD27@thesba.com> <55F752E7.9070801@gmail.com> <D062C4F7-B56E-422F-A563-C7C4A16D36B0@thesba.com> <55F9747F.4070708@gmail.com> <738E9B97-6D20-4E37-85E0-994003ACDFC1@thesba.com> <55F9B168.9010007@gmail.com> <61163E50-AF39-4F69-B740-7F2D40129DB1@thesba.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Wed, 16 Sep 2015 22:09:09 +0100
To: Robert Williams <rewilliams@thesba.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <8DB5E140-07D1-457D-AE32-F13D230E3CB3@gmail.com>
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

On 16 September 2015 20:56:22 BST, Robert Williams <rewilliams@thesba.com> wrote:
>On Sep 16, 2015, at 11:14, Rowan Collins <rowan.collins@gmail.com>
>wrote:
>> 
>> Robert Williams wrote on 16/09/2015 18:37:
>>> If they were null, then PHP wouldn’t spit out errors about undefined
>variable accesses
>> 
>> Once again - PHP does not spit out errors when you access an
>undefined variable. It spits out Notices in case you've done it by
>mistake. Maybe you're thinking of JavaScript?
>
>In our shop, notices are most definitely errors. And notices aren’t
>graceful error handling. I think PHP also also regards them as errors
>(thus the ability to catch them with an error handler) - it’s just a
>lower grade of error.

I think the term "error" in "error handler" is just a misleading historical accident, like "type hint" (which does produce an error!). I can certainly sympathise with wanting to run without any notices - they are generally hints for writing better code. In the vast majority of cases, though, that means working out *why* the variable is undefined, otherwise you might as well just use the @ operator to say "I don't care about this notice".


>That’s great in theory, but in practice, programmers’ code must
>frequently collaborate with other people’s code, often code from
>outside their organization. In these cases, they don’t have the control
>to just fix the problem on the other side. 

This still implies that there's a common problem to fix, which I just don't believe. The number of places where the following all hold true must be vanishingly small:

- the third-party code is dumping bare variables into your scope (globals, or a file-level include are the only mechanisms I can think of)
- they do so unreliably, in the sense that different variables will be set under different circumstances
- you/they have used null as a value which needs to be positively asserted, not taken as the default state, so that isset() does not meet your needs
- you have no way of presetting the variable to some other terminal value to detect when it is  explicitly set


> And in some cases, like with
>config files that set bare variables, there’s really nothing wrong with
>the way it’s done that needs to be fixed. Some folks might prefer to
>use a different model, but that’s just a preference.

Well, there's still a fix beyond "ignore the notices by using exists()" - you could preset all the variables to their default values, or a sentinel "illegal value", before including the config file.

Still, at least it's a concrete example at last.


>In a dynamic
>language like PHP, I really don’t understand how folks can *not* see
>that as an oversight.

I've not found evidence that any other language treats variables in the proposed way, so it really doesn't feel like an "oversight" to me, but a request for a new and quite unusual feature.


> Further, we can do this for everything else…
>constants, array elements, object properties, functions, and even
>classes, so why not variables?

A fair question; one of the big differences with things like classes and functions is that they're declared, once, and then fixed; their scope is also likely to cross module boundaries - a class definition is accessible from any scope, for instance.  A local variable has none of these properties - on the one hand it has no explicit declaration, only "initialisation" the first time you write to it; and on the other, it is a label that exists only inside the current function.

But yes, from a completeness point of view, it does make some sense. My fear is that the people who don't understand why isset() does what it does will think it's the answer to some imaginary problem, and end up more confused than ever when their code breaks. If the function had been proposed as a debugging aid, maybe filed under Reflection or debug_variable_is_initialised, I might have more sympathy, but that's not how it's been presented.


> There's even have precedence for
>controlling behavior based on variable existence in extract(), so PHP
>itself does it in ways that directly affect the user, but the user
>can’t do it.

I can see where you're coming from, but other than not having such a function pair at all (which I'd personally be fine with - they feel like holdovers from a bygone age) I'm not sure how else compact()/extract() could work. It's not so much that they check variable existence, as that the list of uninitialised variables is infinite, so would be tricky to work with...

Regards,
-- 
Rowan Collins
[IMSoP]