Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88126
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain craigfrancis.co.uk designates 209.85.212.179 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
Date: Wed, 9 Sep 2015 16:54:37 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com> <55DD4269.4090402@gmail.com> <6348DFA7-04BD-41BB-A500-17A8A531B56C@craigfrancis.co.uk> <55DDA4C9.9040603@gmail.com> <3C69BF4B-52E6-4D04-8601-8D23DFCC538E@craigfrancis.co.uk> <55DDD60F.5090509@gmail.com> <8C74463E-DBA2-4015-8159-0B44D973387F@craigfrancis.co.uk> <55DE0907.6040904@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>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: craig@craigfrancis.co.uk (Craig Francis)

On 8 Sep 2015, at 19:22, Rowan Collins <rowan.collins@gmail.com> wrote:

> It's also a "quirk" in the sense that suppressing that warning for a =
plain variable is an odd thing to want - if you've assigned meaning to =
that variable you should be initialising it somewhere so that your code =
is more readable and less fragile.



I don't think it is an odd thing to suppress a warning for a plain =
variable.

For example, on a blog you may have a list of articles, which is used by =
both the admin and users, but the (MVC) controller might set an =
$add_url, so a link to add a new article can be displayed...

Controller:

    if (IS_ADMIN) {
	$this->set('add_url', '/admin/articles/add/');
    }

View:

    <?php if (exists($add_url)) { ?>
	<p><a href=3D"<?=3D html($add_url) ?>">Add article</a>
    <?php } ?>

Admittedly in this case the controller could be updated to something =
like the following:

    $this->set('add_url', (IS_ADMIN ? '/admin/blog/add/' : NULL));

But it gets more complicated when you can have multiple things appearing =
(or not) on a page.




> I admit this does partly come down to pre-judging any code that would =
use empty($foo) as "bad", but the warning issued when you access an =
uninitialised variable already makes such a judgement. And if people are =
already confused by the relationship between isset() is_null(), empty(), =
etc, adding yet another variant is likely to hurt rather than help.



I completely agree that we shouldn't be adding more functions lightly, =
and it's why I'm still not completely sold on the idea myself.

I think the main two negatives is adding yet another function =
(confusion), and that it will take a long time before developers can use =
it everywhere.

But, the thing that wins it over for me is that isset() seems to be =
(mis)used by a lot of developers as a function to check if the variable =
exists (not that the variable has a value).

So if implemented, in a few years (decades?), I suspect the exists() =
function would be the first function that comes to mind, instead of =
array_key_exists() and isset().

Actually, in a few years time, if developers did their NULL checks with =
"=3D=3D=3D NULL", then isset(), is_null(), array_key_exists(), and =
empty() could all be deprecated :-)


Craig





On 8 Sep 2015, at 19:22, Rowan Collins <rowan.collins@gmail.com> wrote:

> On 7 September 2015 14:11:05 BST, Craig Francis =
<craig@craigfrancis.co.uk> wrote:
>=20
>> But then again, I don't think it's a quirk that "you don't get a
>> warning when passing a completely undefined variable to isset()", as =
I
>> don't see isset() as a normal function.
>=20
> What I meant is that people seem to interpret isset() as having a =
special case for null values, and want that special case to go away. I =
was suggesting you could instead see it as a version of is_null with a =
special case to stop it complaining about non-existent variables. This =
makes sense, since in practice a "non-existent" variable (note: not =
array item or property) always has the value "null".
>=20
> It's also a "quirk" in the sense that suppressing that warning for a =
plain variable is an odd thing to want - if you've assigned meaning to =
that variable you should be initialising it somewhere so that your code =
is more readable and less fragile.
>=20
>=20
>> With the `exists($foo['bar']['baz'])` example, I just see that as a
>> simple: if $foo exists, and contains the key 'bar', and contains the
>> key 'baz' (no need to check values).
>>=20
>> Like isset() I see exists() as a special function that isn't passing =
a
>> variable in, but PHP doing some analysis of the thing in the =
brackets.
>=20
> OK, thinking about it some more, I can see it would be convenient to =
have a special syntax for array_key_exists() which looked the same as a =
normal array-index access; basically some magic parser rule that turned =
exists($foo['bar']) into array_key_exists($foo, 'bar') Looking at the =
generated opcodes, that could indeed be quite similar to how isset() =
works internally.=20
>=20
> If such a function/syntax were built, I would argue that a plain =
exists($foo) should be a parse error, because there is no key to check, =
only a single value - it would be equivalent to array_key_exists($foo, =
null) or array_key_exists(null, $foo). For that reason, it should =
probably have a name that made its purpose clearer, too, but I'm not =
sure what that would be.
>=20
> I admit this does partly come down to pre-judging any code that would =
use empty($foo) as "bad", but the warning issued when you access an =
uninitialised variable already makes such a judgement. And if people are =
already confused by the relationship between isset() is_null(), empty(), =
etc, adding yet another variant is likely to hurt rather than help.
>=20
> Regards,
> --=20
> Rowan Collins
> [IMSoP]
>=20