Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92423 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56239 invoked from network); 18 Apr 2016 18:39:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Apr 2016 18:39:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.163 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.25.163 mx207.easyname.com Received: from [212.232.25.163] ([212.232.25.163:52973] helo=mx207.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 36/0C-11975-DF925175 for ; Mon, 18 Apr 2016 14:39:57 -0400 Received: from cable-81-173-133-226.netcologne.de ([81.173.133.226] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1asE5S-0002vK-2C; Mon, 18 Apr 2016 18:39:54 +0000 Reply-To: internals@lists.php.net References: <57103A46.6040803@garfieldtech.com> <5710BA79.5060108@lsces.co.uk> <57110DC5.8000007@garfieldtech.com> <571338E6.50507@fleshgrinder.com> <57145AF7.7060607@garfieldtech.com> <57149405.2040701@lsces.co.uk> <57151210.7040704@garfieldtech.com> <57152641.7050602@gmail.com> To: Stanislav Malyshev , Larry Garfield , internals@lists.php.net Message-ID: <571529EB.1000501@fleshgrinder.com> Date: Mon, 18 Apr 2016 20:39:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57152641.7050602@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0L3IrLNCouwaBsfwEBaMQ3SNHrSk7UKAL" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration From: php@fleshgrinder.com (Fleshgrinder) --0L3IrLNCouwaBsfwEBaMQ3SNHrSk7UKAL Content-Type: multipart/mixed; boundary="ffrO37HCOE0Pgc3DEXdNUn0o30N1HH6hO" From: Fleshgrinder Reply-To: internals@lists.php.net To: Stanislav Malyshev , Larry Garfield , internals@lists.php.net Message-ID: <571529EB.1000501@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration References: <57103A46.6040803@garfieldtech.com> <5710BA79.5060108@lsces.co.uk> <57110DC5.8000007@garfieldtech.com> <571338E6.50507@fleshgrinder.com> <57145AF7.7060607@garfieldtech.com> <57149405.2040701@lsces.co.uk> <57151210.7040704@garfieldtech.com> <57152641.7050602@gmail.com> In-Reply-To: <57152641.7050602@gmail.com> --ffrO37HCOE0Pgc3DEXdNUn0o30N1HH6hO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/18/2016 8:24 PM, Stanislav Malyshev wrote: >> to have them calls them a "billion dollar mistake", many languages >> actively avoid having NULL in favor of something deliberately more >> structured. NULLs are a very common cause of avoidable fatal errors i= n >> many languages (including PHP). NULLs are rude to users of your API, a= s >> it balloons the error handling code they need to deal with. >=20 > I think this description is misleading in a way. Nulls are immediate > causes of many errors, technically, in a meaning that "if I find null > where I expected to have DB connection, I get an error" - but this is > only a technical cause. The *real* cause is the failure to check whethe= r > your attempt to connect to the database succeeded, or that you have > proper DB configuration, or such, and null is just a symptom of that > error - and that error is not automagically fixed by having some other > object instead of null. You have to actually design and write code for > it, there's no replacement for it. >=20 > So declaring null "cause of all evils" is ignoring the real causes and > blaming immediate technical cause instead, and it would not be helpful.= > It is true that for some languages with more complex type systems it is= > possible to largely get rid of nulls by using those complex types and > ensure type system controls for all checks at least to be present (note= > that doesn't guarantee proper function either, since no type system can= > ensure you handle the case of missing DB connection properly, it just > can ensure you have a branch for it). But that requires much more > complex and involved type system that PHP has - or, in my opinion, > should have. >=20 I agree with Stanislav here. *NULL* is not evil per se and just because some functional languages get some attention right now does not mean that they solved the biggest mistake in CS history. On the contrary, they just invented another way of handling it by introducing new types that require more book keeping and by refusing to compile if they encounter a place where proper handling is missing. As I wrote earlier, we could introduce such a feature into the language. However, static code analyzers can already provide this functionality. People just need to use them. TL;DR *NULL* is just fine if used correctly and we cannot make sure that people use it correctly. --=20 Richard "Fleshgrinder" Fussenegger --ffrO37HCOE0Pgc3DEXdNUn0o30N1HH6hO-- --0L3IrLNCouwaBsfwEBaMQ3SNHrSk7UKAL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFSnvAAoJEOKkKcqFPVVrf1kP/0vr7CkI1fidW9cxqM45yEAy at3wTN1WxM75HUefrxW5LO67s9qlv+0H8ACOFGny4PX+DpBLOHhN3E644AZQotQ+ ClOvjGpCvVP0tTW8/+TXAjEyYNGaDvxq+ihW7AJhjo9y0eZI0d69PvHINw7I2OvK O+6i7gKT5LhSmsGuT/GFyHYvWqPFZri5iH61YVa36ji8vOB8SAEImJa5i5b1hbZT 7fEelMIoqJENTPuLwXtB3JFVo1gwW8FsHgcGqZs1kmnHAt00rAVrTRWR6g1kxDSN oN9fFMjrEnhVpQB+L0hjf7ShMNVGsASzoPRU2WOie5HKsk4SWRDI6TA2RRuQvdlV MHSKkM1jqCIxCZwWJsY9ZexHOG597SOGXItlQMs63zK+kS2rgfST3z6wr7qPF+yy vjnkqQNi6nPF0fwCM4MK77bfIU3tzr6BHrZqb0gm0kfKf6QnYZzhFrNWnKEjg8WZ U1NrX9FvviLGDt8ed/YQRbBKO1UMBfZ3qqdhyrYrL9/ChdXNir3zhn1eAT0RS8fP UGFMtkjDjbF9XNdLsXI1ejstvut4U6AnLrvmuPudkllV8K5jR4QGmnMAty30WLbi wlBv2JSPSdYh5zVJh7DzFidMhpuehctRdJYafL7AU86g8ZiuaKWzx0piHOIZ2SaJ bMdXWL+ri+uRDhYeXe3B =rgTl -----END PGP SIGNATURE----- --0L3IrLNCouwaBsfwEBaMQ3SNHrSk7UKAL--