Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88200
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.211 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>
CC: internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
Thread-Index: AQHQ36zP6Wb5e1HnokKnJlazAkejtZ4eJ62AgABxe4CAAAPLgIAAJlKAgAAUa4CAACGZAIAAGymAgAjS3QCAAJOjgIAA+D+AgAA5fACAB+afgIAB6WsAgAFo8ICAACyWAIAHac+AgAAGeYCAAD+qgIAAAnkAgABF9ACAAAG1gIAAJ92A
Date: Mon, 14 Sep 2015 22:46:01 +0000
Message-ID: <09369945-76FE-4E08-9C2C-15FB0577AD27@thesba.com>
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>
 <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>
In-Reply-To: <55F72CA9.2060301@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/signed;
	boundary="Apple-Mail=_3DE4AA12-F199-4604-92A4-EDA450C2C16A";
	protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rewilliams@thesba.com (Robert Williams)

--Apple-Mail=_3DE4AA12-F199-4604-92A4-EDA450C2C16A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Sep 14, 2015, at 13:23, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
> No. There's no reason for null to exist if isset returns true on null.
> If one doesn't understand that, one should not be using null at all.


Nonsense. It just means that one isn=92t using null the way you do. =
You=92re saying people shouldn=92t be programming to distinguish between =
declared-but-defined-null and undeclared. But the fact is, from user =
land-POV, null *is* a value, and it=92s frequently used where a variable =
needs to be defined with a sentinel value that clearly flags the =
variable as not having an otherwise valid value. The alternative is to =
use magic values as sentinels instead =97 e.g., 0 or 9999 for an =
integer, or empty-string for a string =97 but that causes all sorts of =
bugs when those values are only rarely legitimate versus never =
legitimate (see: Y2K). Magic values also tend to make code less =
readable.

Programmers have been using null like this for decades, e.g., C strings. =
It=92s also quite common in databases, where, at least with MySQL, null =
happens to translate directly to PHP null when data are queried. And =
frankly, I see nothing wrong with recognizing that a variable exists in =
the symbol table but has no real value versus one that doesn=92t even =
exist. It=92s like the difference between having a car in your garage =
that is out of gas versus not having a car at all.

And again, PHP itself clearly distinguishes the two states everywhere =
but in isset() and empty(). IMHO, isset() and empty() are both misguided =
(beyond the null problem) because they attribute meaning to certain =
values of user land data, and they bundle several checks together. And =
they do all that without any domain knowledge controlling what values =
are or are not valid. If I=92m counting eggs in my basket, zero is most =
definitely a valid value, while it=92s not if I=92m looking at the =
weight of a specific egg. PHP shouldn=92t be making that decision for me =
in blanket form. Yet, that=92s exactly what these functions do. As I =
said, they=92re misguided, right up there with register_globals. (They =
lead to similar security bugs, too.)

Incidentally, what=92s the difference, philosophically, between these =
two:

$foo =3D null;
var_dump(isset($foo)); //false

$foo =3D [=91bar=92 =3D> null];
var_dump(array_key_exists(=91bar=92, $foo)); //true

If a variable that=92s declared yet defined as null can=92t =93exist=94 =
as decided by isset(), why can an array element that=92s declared yet =
defined as null =93exist=94 as decided by array_key_exists()? Is the =
symbol table really that different from an array? It gets weirder yet =
where the two start to overlap in user land:

$foo =3D null;
var_dump(isset($foo)); //false
var_dump(array_key_exists('foo', $GLOBALS)); //true

$array =3D ['foo' =3D> null];
$bar =3D null;
extract($array);
print_r(get_defined_vars()); //now have both $foo and $bar in scope

I don=92t understand how anyone can see this as being consistent and =
self-explanatory, especially if we assume the words =91exists=92 and =
=91set=92 to have their traditional programming meanings (=91set=92 =
meaning to assign a value and =91exists=92 meaning there=92s an in-scope =
entry with the given name in the symbol table).

--
Bob W.

--Apple-Mail=_3DE4AA12-F199-4604-92A4-EDA450C2C16A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV904YAAoJEFBTSdRZ0ub3YJYP/i+ZuY9lSOdlT6OZeucOkq/j
3D2bS7lrXH5fJfdg+MDeHKMGCD62neR2xLtVx0BO5fElWeiTMWSNeI7pQ8MXZE/b
0rPk3URZPo5ZKPfxNUyAMaNOZYmCeRMHBsXpY8B0oO7Kd7R6bEX3uSQDtPcU+x9p
Qq40auVIr7AlQ8LlzhydgdKSw0HhH4arjXahZiFKoTY6Nf/0Tmjt5WQ16FAVpgMi
xpxj4u7rhYzcvZjxpJ03VJhfRzHx2Lsxi3gB1uJk0KGf1YtxsTXFsYh7SCD9Q3i1
P7Rw3WkX7v7aGjbEEfHkE4OVdZYIXh0VtbHlYAArKJ3jTNNJ6BqOr9v4Iake3CSg
cRsb2F7DjPPfWZmVAovGs7cjJAmosLkUqEhbzEd7MQfJE56lTN8hbHSERwZz4gtB
PHIIzHWMOek+2o8YIUHJtYXI7oZbecEZ95oUqZGDZoojuCdL9Myls9emljuX/1I1
217qXlsAcF70DIRwhNk0HdCkQzLUaouFfJb57iTRP3id/P+z30p2CYc4UHIZTsr4
WjELvgWkmlUhKMwxvCvRlybfjm2DrgnpGJ0mXyplkkcoD9JxiDwekHmUl8j4g75y
bOrU24bAcwutJgbpR0dKty8iqMJXlB+k2sCBwCykrCcOBt9uB50FI+xDwy+Fp5uK
blWFFjT9SYWFakRcdXn1
=efcS
-----END PGP SIGNATURE-----

--Apple-Mail=_3DE4AA12-F199-4604-92A4-EDA450C2C16A--