Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93775
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.164 cause and error)
Reply-To: internals@lists.php.net
References: <d9847a18-49c0-d2d0-db4e-e0d6e6685ba0@fleshgrinder.com>
 <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Message-ID: <f1a54f8e-03d3-b271-589b-5bc0bb51287f@fleshgrinder.com>
Date: Sat, 4 Jun 2016 19:51:31 +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: <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="Lq02Qd0DJGd3rv4wVrLvwrL7g1he8KqPb"
Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
From: php@fleshgrinder.com (Fleshgrinder)

--Lq02Qd0DJGd3rv4wVrLvwrL7g1he8KqPb
Content-Type: multipart/mixed; boundary="1O4CQMDXSVaAE3jcoihn2RgfXshDqUxPb"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Message-ID: <f1a54f8e-03d3-b271-589b-5bc0bb51287f@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
References: <d9847a18-49c0-d2d0-db4e-e0d6e6685ba0@fleshgrinder.com>
 <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>
In-Reply-To: <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>

--1O4CQMDXSVaAE3jcoihn2RgfXshDqUxPb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/4/2016 7:37 PM, Sara Golemon wrote:
> On Sat, Jun 4, 2016 at 5:12 AM, Fleshgrinder <php@fleshgrinder.com> wro=
te:
>> I prepared my first contribution to internals:
>>
> Welcome!
>=20

Hi Sara, nice to eventually becoming part of it. :)

On 6/4/2016 7:37 PM, Sara Golemon wrote:
> I've put a couple minor notes on the implementation.  Nothing
> technically wrong, just style and micro-perf.
>=20

Many thanks for the code review and feedback!

On 6/4/2016 7:37 PM, Sara Golemon wrote:
>> I would like to discuss the proposed new function here.
>>
> My number one issue with this PR is that it's all PHP code.  There's
> nothing in here that couldn't be done as a composer installable
> library wrapping the existing gettype() and mapping around the
> oddities you mention in the RFC.  Wouldn't it be better to make
> something that'll work across PHP versions, rather than something only
> available in 7.1?
>=20

Sure but the goal is to have a function in PHP that actually returns the
proper type name of a variable. I think it is wrong that one requires a
userland extension just to get the totally normal type name of something.=


(The above only refers to the non-extended mode.)

On 6/4/2016 7:37 PM, Sara Golemon wrote:
> Beyond that, though on a similar vein, the extended format feels like
> unparsable overkill for any use case but logging, and in the case of
> logging you probably want the value as well which calls for something
> more in the var_*() family.  var_describe, perhaps?
>=20

I was thinking about type_info() right now but var_info() would also be
nice I guess.

On 6/4/2016 7:37 PM, Sara Golemon wrote:
> By comparison, when it comes to code logic, there's nothing I do with
> (typeof($foo, true) =3D=3D=3D 'bool true') that I can't do with
> ((gettype($foo) =3D=3D=3D 'boolean') && $foo).  I'll grant that the for=
mer
> is marginally more readable, but only in the most generous, liberal
> sense.
>=20

Arg, none of the above examples is a goal of mine for this function.
(is_bool($foo) && $foo) is the idiomatic way to perform such things.

On 6/4/2016 7:37 PM, Sara Golemon wrote:
> If you'd like a new typeof() function, I think we should design it to
> be much more robust like what Marco suggested.  I don't care if that's
> ReflectionType or ReflectionVariable or ReflectionBananaForScale.
> Something that serves both programmatic needs by having ->isCallable()
> ->isNumeric() etc methods *and* serves human readability through a
> __toString() method seems to make much more sense.
>=20

As I answered to Marco, I can put that in the future scope section since
I see the usefulness of it. But I would prefer to not extend the RFC
with it. (However, I am more than open to the idea of removing the
extended mode.)

On 6/4/2016 7:37 PM, Sara Golemon wrote:
> Lastly, with all the work going into gradual typing, I can see us
> specifically wanting the name `typeof` at some later point.  So at the
> VERY least, I'd rename this to var_type() or similar.
>=20

I addressed this in the RFC. I do not think that *typeof* would be a
good operator in PHP because we already have *instanceof* and most
discussions in the last months where going into the direction of
extended the functionality of that instead of introducing another one. I
also propose in the open issues section to use *is* as an operator
instead of both *typeof* and *instanceof* because it does not have any
relation to the kind of a variable. It is short and complements other
operators like *and* plus *or* nicely. It also reads extremely nice:

  if ($var is bool);

  if ($var is Fleshgrinder\Examples\Example);

That being said, I actually like the var_type() name. We already have
many var_* functions but no type_* functions so far. I'd happily change
it to that if others think that it is a good name. I went for typeof()
because of the broad language support (illustrated in the RFC) and the
close type relation but the relation to variables is equally close in my
opinion.

--=20
Richard "Fleshgrinder" Fussenegger


--1O4CQMDXSVaAE3jcoihn2RgfXshDqUxPb--

--Lq02Qd0DJGd3rv4wVrLvwrL7g1he8KqPb
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

iQIcBAEBCAAGBQJXUxUoAAoJEOKkKcqFPVVrC78P/3gL2F/XhmUgBFSFTxqfE9wi
PqV7T4TyCE2P76y4X2sogCZ0mxck97P9DCPKJeqdPmBEU/lo32Ju1pnrwmKUUXzX
K/YdO1kniFz9wFMPaH/1rHD0lmwZf68iczl7P64156B1SMN2a2jDFhDQH/nXsBeK
5wODfVPEHIleRQdsq7zJrkdV8uMM+LzAwKGAtoq8Z891U9GLSv9doN7fZBMDOg09
EytJMkXXtlGz3MF2qxawMYQeLaoTegiQTcrTqPb9YVUlevWB2806FfcMCKgQ00kK
8unoAbkorRuZ0iBs0m7evoZOZLTnMimqM/ZE06dW+NVXudYt0yLZOMEkPVsLD6A4
cCbnhFzUnXwatUXvcwDYQajdfM0cmGXMlcTZyN2p5bT3kWP7swzxFF24MgpOjmzk
P1MFOpON0XdAJfjoLzPiUsw6q8JvAM5qCsf1qJhPX6sou6ZVoFNxvbsmthjpRcbb
0FOE9Bi6WuHngzlhkiV3ncluNnrS7kVkh89ErX5gtKJP67t7uaxQPL7aJAbBH1EC
vfOuQyqUto9bBltD3IZdbf6O6HexdYhLD2q4tX0jo4x0C//cMFRI3c86z2R7D205
RqVA/lvDE6FUEvKfud3h9ttoaLjtL60HJYvhGeC4p7iQaqv5Y/eEEyXgvz9oSGPQ
WekIaAw8ZV99xeGGs045
=4ZqO
-----END PGP SIGNATURE-----

--Lq02Qd0DJGd3rv4wVrLvwrL7g1he8KqPb--