Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87987
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.180 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <55DE0907.6040904@gmail.com>
Date: Tue, 1 Sep 2015 10:29:10 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <1F615BCD-1B9B-4C51-A210-869F1AA1F6E3@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>
To: Rowan Collins <rowan.collins@gmail.com>,
 Ryan Pallas <derokorian@gmail.com>,
 James Gilliland <neclimdul@gmail.com>,
 Bishop Bettini <bishop@php.net>,
 Stanislav Malyshev <smalyshev@gmail.com>,
 Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: craig@craigfrancis.co.uk (Craig Francis)

Hi Rowan, Ryan, James, Bishop, Stas, Lester,

I've been giving this some thought over the weekend, and I agree with =
what you are all saying, but I think there is an element of confusion in =
the PHP programming community that needs to be addressed (somehow).

Yes, we probably should not be giving special meaning to NULL, as James =
mentions (although I probably still will).

And to be fair, I still can't think of an example where isset() can be =
used on a standard variable. All my examples are really array based, and =
better addressed with array_key_exists() - where Rowan does a great job =
of explaining the different examples on stackoverflow:

  http://stackoverflow.com/a/18646568/2908724

Trying to get to route of the confusion though, I think it might be down =
to how the code can be read. So if we take:

<?php
  $a =3D 1;
  $b =3D NULL;
  var_dump($a);
  var_dump($b);
  var_dump($c);
  var_dump(isset($a));
  var_dump(isset($b));
  var_dump(isset($c));
?>

Or using an array instead:

<?php
  $v['a'] =3D 1;
  $v['b'] =3D NULL;
  var_dump($v['a']);
  var_dump($v['b']);
  var_dump($v['c']);
  var_dump(isset($v['a']));
  var_dump(isset($v['b']));
  var_dump(isset($v['c']));
?>

In both cases (and ignoring the undefined variable error), we get:

  int(1)
  NULL
  NULL

  bool(true)
  bool(false)
  bool(false)

But if we ignore the manual for a minute:

  http://php.net/isset

I think a good comparison to what that code reads as, vs what PHP does, =
can be summarised as:

  Read as: The variable is set (exists).

  Executed as: The variables *value* is set.

Where NULL is not considered a set value.

So when we have:

  if (isset($v['a'])) {
  }

It's not saying that the key 'a' is set (exists) on the array $v.

Instead its saying that the key 'a' has a set value (not NULL) on the =
array $v.

Where this is made more of a common problem because there are many =
array_* functions, and they rarely come to mind when your not thinking =
of an array like operation.

This situation might be improved by re-wording the manual a bit.

Having headings like "This also work[s] for elements in arrays", makes =
it sound all inclusive and *the* function to use.

Whereas I'm starting to get the feeling that isset() is actually a =
function that probably should be avoided (I'll skip this tangent for =
now).

Personally I still like the idea of an exists(), because I feel that is =
how many programmers treat and use the isset() function - simply because =
they do use NULL as a valid value, and either haven't read the manual, =
or forget the exception that is mentioned on line 1 (something I've done =
a couple of times).

Although I realise it will take many years before anyone can start using =
it.

Craig








On 26 Aug 2015, at 19:44, Rowan Collins <rowan.collins@gmail.com> wrote:

> Craig Francis wrote on 26/08/2015 18:07:
>> I provide examples to help explain that I (and I suspect most =
developers) default to using isset which works on either.
>>=20
>> Just because there is a function, which does not exactly roll off the =
tongue (plus the fun of the needle/haystack ordering issue), does not =
mean it gets used (even if it is the correct thing to use).
>=20
>=20
> That's all very well, but what is the Internals community supposed to =
do about it? Does the documentation need to be improved to point out =
that there is a better function to use for this case?
>=20
>> I say "or key" because developers use the isset function on both $var =
and $var['key']... yes, I know they are different, but when you are =
coding in PHP an isset check is an isset check (well it isn't, because =
the variable may technically exist).
>>=20
>> If this is a problem, maybe PHP should raise a notice when isset is =
used on arrays?
>=20
>=20
> It's only a problem in the same way that using file_exists() is a =
problem when you actually wanted the functionality of is_readable() - =
both functions exist, and it's not the language's responsibility to =
guess which you meant.
>=20
>=20
>=20
>>>> where NULL may be a perfectly valid value.
>>> It's not that NULL isn't a valid value; it's that "doesn't exist" =
isn't a meaningful state for a variable. It's like checking if the =
current line number is greater than 100, it shouldn't mean anything to =
the compiled program. See the SO answer I linked earlier for more =
thought experiments along these lines.
>>=20
>> I think you have been spending too much time in C.
>>=20
>> Most of the PHP code bases I've worked on set variables to NULL at =
some point (and they are not calling unset, because that isn't the =
intention).
>=20
>=20
> Perhaps my double negative made it unclear, so I will restate: there =
is nothing wrong with setting a variable to NULL. There is also nothing =
wrong with calling unset() on a plain variable, e.g. to make it obvious =
to readers of the code that this variable should not be used below this =
point.
>=20
> There IS something wrong with any code which needs to distinguish =
which of those two things happened, at run-time, because such code would =
be incredibly fragile and hard to follow.
>=20
> You could, if you wanted, emulate a boolean variable by using =
$foo=3Dnull for true, and unset($foo) for false, but why not simply have =
a boolean variable?
>=20
> [Incidentally, I know barely any C, but program PHP for a living.]
>=20
> Regards,
> --=20
> Rowan Collins
> [IMSoP]
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20