Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92488 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24465 invoked from network); 19 Apr 2016 20:03:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Apr 2016 20:03:24 -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 77.244.243.86 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.86 mx105.easyname.com Received: from [77.244.243.86] ([77.244.243.86:37315] helo=mx207.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2D/56-22821-B0F86175 for ; Tue, 19 Apr 2016 16:03:23 -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 1asbrj-0005dV-JV; Tue, 19 Apr 2016 20:03:19 +0000 Reply-To: internals@lists.php.net References: <570E99AC.3090804@fleshgrinder.com> <570EA5EB.8090501@fleshgrinder.com> <570EAB0D.6080706@gmail.com> <570EB67E.8010908@garfieldtech.com> <5B147E88-CC0A-4CBC-A49D-C7FE3BF557C0@zend.com> <6F.C3.12455.94C5F075@pb1.pair.com> <20160414094440.GF19347@phcomp.co.uk> <570FD94F.90703@fleshgrinder.com> <570FE8A9.4020809@gmail.com> <20.53.29891.17401175@pb1.pair.com> <57110BCD.5030009@garfieldtech.com> <571124C2.9040606@gmx.de> <57112F31.8070209@garfieldtech.com> <57166BC9.8020602@fleshgrinder.com> To: Zeev Suraski Cc: "internals@lists.php.net" Message-ID: <57168EF6.3050004@fleshgrinder.com> Date: Tue, 19 Apr 2016 22:03:02 +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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DGvr6W3jWNNFR1QQmn6ih4lKlb0MnGr2R" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] Re: Improving PHP's type system From: php@fleshgrinder.com (Fleshgrinder) --DGvr6W3jWNNFR1QQmn6ih4lKlb0MnGr2R Content-Type: multipart/mixed; boundary="qOHGXlTitjtwHTIIvaU32Po951w4H7W9A" From: Fleshgrinder Reply-To: internals@lists.php.net To: Zeev Suraski Cc: "internals@lists.php.net" Message-ID: <57168EF6.3050004@fleshgrinder.com> Subject: Re: [PHP-DEV] Re: Improving PHP's type system References: <570E99AC.3090804@fleshgrinder.com> <570EA5EB.8090501@fleshgrinder.com> <570EAB0D.6080706@gmail.com> <570EB67E.8010908@garfieldtech.com> <5B147E88-CC0A-4CBC-A49D-C7FE3BF557C0@zend.com> <6F.C3.12455.94C5F075@pb1.pair.com> <20160414094440.GF19347@phcomp.co.uk> <570FD94F.90703@fleshgrinder.com> <570FE8A9.4020809@gmail.com> <20.53.29891.17401175@pb1.pair.com> <57110BCD.5030009@garfieldtech.com> <571124C2.9040606@gmx.de> <57112F31.8070209@garfieldtech.com> <57166BC9.8020602@fleshgrinder.com> In-Reply-To: --qOHGXlTitjtwHTIIvaU32Po951w4H7W9A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/19/2016 8:48 PM, Zeev Suraski wrote: >> but it does not help with primitive types. :( >=20 > Which is fine. Primitive types can and should get dedicated solutions.= There's really no need for allowing over creativity with userland-custo= mized scalar types. >=20 Hmmm... nope. I already brought various examples where I personally see the strength of union types and that is exactly with the primitives.[1] *int|string* is so powerful if you deal with MySQLi and its BIGINT stuff because I can fully type hint it now (like the /mysqli/ extension does in C) and check very fast if I need to use GMP or not. I can only repeat. I am fully supporting to block union types if we instead commit to the introduction of additional primitive types (as outlined in the generics RFC)[2] and operator overloading in userland. However, use cases remain and union/intersection types can help especially if you do not want any kind of is-a relationship in your classes. In other words, we do not want to introduce an additional interface for something because we do not want the instance to pass through other checks. Or, of course, the situation where it is simply impossible for me to introduce the interface: built-in classes. I might want to decorate them and pass through all checks but I cannot because, well, how? [1] http://marc.info/?l=3Dphp-internals&m=3D146080503103988&w=3D2 [2] https://wiki.php.net/rfc/generics#related_enhancements > I believe you think I meant that instead of checking that $b's class ac= tually implements foo and bar, we'd check whether $b has all of the metho= ds needed by foo and bar - which means that theoretically means that it m= ay have methods foo() and bar() but not actually 'officially' implement t= heir respective interfaces. But there's no reason to do it this way and = that's not what I meant. > Instead, with my proposal, a $b object whose class implements both foo = and bar - will automatically be accepted as one that also implements baz.= The checks will be conducted at the interface level, not the function l= ist level. In other words, if $b doesn't explicitly implement baz, we'd = take a look at 'baz', see it's comprised of foo & bar, and check whether = $b's class implements them. >=20 > At this point, I can't imagine any negative side effect to automaticall= y deducing that an object that implements foo and bar also implements baz= (other than a small performance hit, probably roughly the same as the AN= D union type). Like I mentioned in my original post, I don't necessarily= think it's needed - I personally see no reason not to add 'baz' to the l= ist of interfaces impl implements, or as you said, replace foo and bar wi= th baz altogether. >=20 interface HouseCat { function drink(); } interface Dog { function eat(); } interface Lion { function drink(); function eat(); } A lion drinks and eats but is neither a HouseCat nor a Dog. This is dangerous and introduces many potential hard to find bugs. Better don't touch it and go for duck typing or the introduction of a dedicated interface: *always* --=20 Richard "Fleshgrinder" Fussenegger --qOHGXlTitjtwHTIIvaU32Po951w4H7W9A-- --DGvr6W3jWNNFR1QQmn6ih4lKlb0MnGr2R 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 iQIcBAEBCAAGBQJXFo79AAoJEOKkKcqFPVVrAGsP/0urP6tvWLdHuc4x3CTi606s A4ms5R961F2rZzSURawMO2+63ZZXaXmx7IGvpFoE2S3MicqfhmvVmT5kFNbJGktm wav693q9rHPACVeBs5y1hy6cm0GFJ4/cEcY26/71Y3IvKadFiV1yum5z8UQwzt1u 3GeOxXo1EZcM2djEanhgtXJudkcenM5Dpd6CdXypThEx9V8PAhF2nLWyGN5PbUzV 67U5eqTR5iztOazluiIVf89oii+ZCDcq5OPmv5j7lVnqu2XEUNYeVtQGqs6voH9A 79/MEBQlJyFWO3qVK8k7hb9jk/h+awy0/LD3/p/mSfI1MiZq8piAgO18Kv0VpFd1 zGXP1fujiB4EL03lA6yma5gE9JQMb45RaF7CdqI1okK9wr/EUSghLEEf78ZL+ar8 OkPF8U0f6xd36mRPEbqaPMSkU175muft1NIWczD6YPmdO8tGBXhmoY/jGwnTjnqq C8TKsg3ncpEQvCwbbfhIKqfak9h7JDfev5buVYUZZ6/dBhuVzEF5EoevfZ/b5hqm LSUoZir5IcKRRA6bw3vh5hHN873FJQ2pAbVS1sxwkkVzlpz3fKWDF0yt9SS+nlSh 6eHKJSmJsSwNWuFA7uXS5Qu+R4pohDO7RA0eVsFlheEzfnmaB2EfSIGD5rTiH5h4 zHegqI8CYwsiyNcfTSxG =tnRs -----END PGP SIGNATURE----- --DGvr6W3jWNNFR1QQmn6ih4lKlb0MnGr2R--