Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88190
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.210 as permitted sender)
To: internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
Thread-Index: AQHQ36zP6Wb5e1HnokKnJlazAkejtZ4eJ62AgABxe4CAAAPLgIAAJlKAgAAUa4CAACGZAIAAGymAgAjS3QCAAJOjgIAA+D+AgAA5fACAB+afgIAB6WsAgAFo8ICAACyWAIAHac+AgAAGeYCAAD+qgIAAAnkAgABF9AA=
Date: Mon, 14 Sep 2015 20:17:19 +0000
Message-ID: <0BEF6D82-CB5F-49F6-A3A4-3267924A0CDA@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>
In-Reply-To: <55F6F08C.1020506@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/signed;
	boundary="Apple-Mail=_E6C1725D-95DE-42C0-BA04-270A36E4F46F";
	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=_E6C1725D-95DE-42C0-BA04-270A36E4F46F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_39582B59-4B38-406C-83E6-6C5ACD2556DE"


--Apple-Mail=_39582B59-4B38-406C-83E6-6C5ACD2556DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I really don=92t understand the resistance to this type of change, other =
than knowing that a fix will necessarily be messy. The fact is, PHP =
distinguishes between a variable that has been declared but defined to =
null and one that hasn=92t been declared. The value of the first may =
safely be assigned, compared, referenced, and so on, while attempting =
any of those things on the second one results in an error message. The =
question of whether relying on those differences is philosophically =
acceptable is a moot point: they *are* different, period, and the rest =
of the language should acknowledge and support that =97 just as do most =
other languages with a similar design (e.g., JavaScript).

Beyond that, the philosophical debate is clearly settled in the real =
world of code. One glance through the comments on the isset() =
documentation page, not to mention the bug reports and the discussions =
on the lists, shows that people have long struggled with this. Based on =
code I=92ve seen from fairly experienced developers, the confusion =
around this has probably led to millions of production bugs, many of =
them in the areas of validation and security. When a particular aspect =
of a language's design promotes bugs to such an extent, it needs to be =
revisited.

I=92m not sure what a good solution is, however. Changing isset() will =
have consequences: making it return true for null will magically fix a =
lot of bugs out there, but it=92ll also break code where the programmer =
understood how it really works. Adding a parameter to control it is =
ugly. Extending defined() to variables might be a good choice, as it=92s =
already doing for constants exactly what=92s needed for variables; the =
only downside is that it would be better-named declared() than =
defined(), but that=92s the case for constants, too, so I can live with =
it. For now, isset() and empty() can continue to work as-is but perhaps =
with a notice and deprecation when used with undeclared variables.

--
Bob W.

--Apple-Mail=_39582B59-4B38-406C-83E6-6C5ACD2556DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">I really don=92t understand the resistance to =
this type of change, other than knowing that a fix will necessarily be =
messy. The fact is, PHP distinguishes between a variable that has been =
declared but defined to null and one that hasn=92t been declared. The =
value of the first may safely be assigned, compared, referenced, and so =
on, while attempting any of those things on the second one results in an =
error message. The question of whether relying on those differences is =
philosophically acceptable is a moot point: they *are* different, =
period, and the rest of the language should acknowledge and support that =
=97 just as do most other languages with a similar design (e.g., =
JavaScript).</div><div class=3D""><br class=3D""></div><div =
class=3D"">Beyond that, the philosophical debate is clearly settled in =
the real world of code. One glance through the comments on the isset() =
documentation page, not to mention the bug reports and the discussions =
on the lists, shows that people have long struggled with this. Based on =
code I=92ve seen from fairly experienced developers, the confusion =
around this has probably led to millions of production bugs, many of =
them in the areas of validation and security. When a particular aspect =
of a language's design promotes bugs to such an extent, it needs to be =
revisited.</div><div class=3D""><br class=3D""></div><div class=3D"">I=92m=
 not sure what a good solution is, however. Changing isset() will have =
consequences: making it return true for null will magically fix a lot of =
bugs out there, but it=92ll also break code where the programmer =
understood how it really works. Adding a parameter to control it is =
ugly. Extending defined() to variables might be a good choice, as it=92s =
already doing for constants exactly what=92s needed for variables; the =
only downside is that it would be better-named declared() than =
defined(), but that=92s the case for constants, too, so I can live with =
it. For now, isset() and empty() can continue to work as-is but perhaps =
with a notice and deprecation when used with undeclared =
variables.</div><div class=3D""><br class=3D""></div><div class=3D"">-- =
&nbsp;</div><div apple-content-edited=3D"true" class=3D""><div =
style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div class=3D"">Bob =
W.</div></div></div></body></html>=

--Apple-Mail=_39582B59-4B38-406C-83E6-6C5ACD2556DE--

--Apple-Mail=_E6C1725D-95DE-42C0-BA04-270A36E4F46F
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

iQIcBAEBCgAGBQJV9ys6AAoJEFBTSdRZ0ub39JwP/0zJIgVPdMVCGj6hyPRWqjFy
D3+HR9qGr3EiafZ1Okm9C6zhkw9l66Hi+LlllMPX1OM+8TsdbVaf2kl826n/j64c
TdVq/8bGVr0gyBYfSirYTyjmSsRTp2BrVL+G5OQa1NMFrSeBTVAdR88Og92G9EG9
ONXM6LPf0K3Lq1mPImQ04hVXrKJgmEOrC4ZTzuIGyqxVK9i1vWzwkarR40DSQUEe
WM38UI/5y/AOO/L30yNFtnRAw76jXYbntLyTz8xBnbnyAD3usx9GusGRPnAQR7zj
d4AgEiGlbHLqg0hJPcpiGFlRkB+5CSlleTjpPAmnA6aUBb6B1SwD2FY5WVsyRk8c
RQemiBaJ0oz2hfbYnlpgz3x3OtUS4uA7GQeMFeVHsKVchLI7gskGVz6Jh1igsOoo
wWYM0tM9hw1wMwvCQL9iMQALk/wprsYmmZ1RbaZrXKR6HrtlastwpkMTOsnRCxZq
dU5P8NexJPKjOK5HsFZhAPyDB7cRwQS9ZbLEtmSQmccb07ubFncxAdzgLvA/PsFE
OBdIpKVikg5DmuH6FbOZjy7J20DoCjBAesj2GhfvGVCy9BudJHSebid7VigOHgZB
9Em9MsLNiWgm7ewNgiFRSFMEE8jU+QXdnzXJLXoDu4nG3A4i8VGAJfiEifSADH2A
hgpWVzoV0ihiNDHmiC40
=WmJ/
-----END PGP SIGNATURE-----

--Apple-Mail=_E6C1725D-95DE-42C0-BA04-270A36E4F46F--