Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94259 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86922 invoked from network); 26 Jun 2016 10:43:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jun 2016 10:43:03 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.87 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.87 mx106.easyname.com Received: from [77.244.243.87] ([77.244.243.87:49555] helo=mx201.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 12/FA-00500-6B1BF675 for ; Sun, 26 Jun 2016 06:43:02 -0400 Received: from cable-81-173-134-219.netcologne.de ([81.173.134.219] 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 1bH7Wl-0005CN-3P; Sun, 26 Jun 2016 10:42:59 +0000 Reply-To: internals@lists.php.net References: <1e1213c6-3e61-3106-98f8-ce7ab74200e2@fleshgrinder.com> To: Dan Ackroyd , "internals@lists.php.net" Message-ID: Date: Sun, 26 Jun 2016 12:42:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6h51setLiRmxXMVgLlxHpk3Twvex1rWco" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC DISCUSSION] var_type From: php@fleshgrinder.com (Fleshgrinder) --6h51setLiRmxXMVgLlxHpk3Twvex1rWco Content-Type: multipart/mixed; boundary="C1wwWioAE5jO1mx26mMxcD6XfO9BJId3U" From: Fleshgrinder Reply-To: internals@lists.php.net To: Dan Ackroyd , "internals@lists.php.net" Message-ID: Subject: Re: [PHP-DEV] [RFC DISCUSSION] var_type References: <1e1213c6-3e61-3106-98f8-ce7ab74200e2@fleshgrinder.com> In-Reply-To: --C1wwWioAE5jO1mx26mMxcD6XfO9BJId3U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/26/2016 12:31 PM, Dan Ackroyd wrote: > Hi Richard, >=20 Hi Dan! On 6/26/2016 12:31 PM, Dan Ackroyd wrote: > As other noted elsewhere by others, the name of the function is > slightly misleading for this case: >=20 > var_type(1 + 1); >=20 > However I don't have a better suggestion. >=20 The name comes from Sara from the original typeof() discussion thread. I understand the arguments of the people but as I already explained on Reddit, the usage of var_type() on expressions like the above is nothing anyone would ever do, especially if the TYPE_INT constant is exposed in userland. One would only use it to get the type of the value that is currently stored in a variable of which the type is unknown. vat_type() or value_type() could be good choices as function name. However, both would introduce new prefixes and I actually do not think that this is a good idea because it will require people to remember more and more and more prefixes which makes no sense. It is a declared goal of this RFC to make is simpler for developers to find what the need (aided by their IDE and brain). Remembering that you can get additional information about a variable (its value, type, ...) via the super old var_* prefix is definitely a good thing, shows visions, and an overall goal. Note that I plan to provide a var_info() function in my next RFC that builds upon this. TL;DR I still like Sara's suggestion and intend to keep it. On 6/26/2016 12:31 PM, Dan Ackroyd wrote: > From the second half of the RFC: >=20 >> const TYPE_FALSE =3D 'false'; >> const TYPE_TRUE =3D 'true'; >=20 > Although as an implementation detail they are present in the engine, > those aren't types in userland. i.e. you can't do >=20 > function foo(true $i_only_accept_true) {} >=20 Yes, I also struggled to actually expose them (and write a comment for them). I searched some code bases and found many usages of literal true and false, this convinced me that there is a need for them. Introduction of true and false as type declarations was also discussed and proposed multiple times (did not make as of yet though). I am definitely open to removing them again! Should we add a third poll? --=20 Richard "Fleshgrinder" Fussenegger --C1wwWioAE5jO1mx26mMxcD6XfO9BJId3U-- --6h51setLiRmxXMVgLlxHpk3Twvex1rWco 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 iQIcBAEBCAAGBQJXb7GwAAoJEOKkKcqFPVVrHVAP/3UzUbC4sC/1mK8hEFM3L7d3 XoesfLh9/WQKXqa97upzrwCC6quZEPoMd9rVy4rAfUrLIenh42CYenyPVYNxaZbm Rp9A1HlPEFFmWP7ScwcU0Tkwzz8zYiRh/slJjLa7LGTlvtlirwoe1NRBIMjLsMo+ BHzLyW5/PLU4sZjAOJpvlyB7i+MgBG3OClExj7SEIdE7NPfXydM495yufbYTElM3 TAl9FSZCA0s5v3FwsiYgGoCS3/UOp3CI7oNMnsVs4onvZ2WfgzV5ckNd0XmZlS/Z 0Zk+fRDsIEMRTmIjAvBqAbx/tttfEIxpfCELZyqRKoZuYHTe0GrSAGHf8GdQZ/P+ gp1cTcSr6NnELiwSctEtdjZ/vwqVqZHie568OXaCmkxCa92wW5dXZC8OgULjrFXM gyp8cOY1PTi6ROA6IFd/E49a5TQlbcB5ezETIQRSY/RJ9Sjdwx8RlJ57Z3KBJhEk TvIaRTN5qYcIuSrPUIKYcVSXWNz4qjOdG613ZexBqNGovDVkf0wesMWjilUogyUw x6i5p6tjQ2YtCSnM27POjuyexmc2frY/imwzbqFgKgLQojyIS0shbq44m/4AJzJQ 6933/DlR7oU6JBmv+SoigIwp/KHKyegQsBSLRF/PYZpN5uLTYc7JAHhibptmrg3s DJS2P/qMgXmS7Ton+92S =S6HA -----END PGP SIGNATURE----- --6h51setLiRmxXMVgLlxHpk3Twvex1rWco--