Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93774
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.214.42 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <d9847a18-49c0-d2d0-db4e-e0d6e6685ba0@fleshgrinder.com>
References: <d9847a18-49c0-d2d0-db4e-e0d6e6685ba0@fleshgrinder.com>
Date: Sat, 4 Jun 2016 10:37:45 -0700
Message-ID: <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
From: pollita@php.net (Sara Golemon)

On Sat, Jun 4, 2016 at 5:12 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> I prepared my first contribution to internals:
>
Welcome!

> https://github.com/php/php-src/pull/1932
>
I've put a couple minor notes on the implementation.  Nothing
technically wrong, just style and micro-perf.

> 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?

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?

By comparison, when it comes to code logic, there's nothing I do with
(typeof($foo, true) === 'bool true') that I can't do with
((gettype($foo) === 'boolean') && $foo).  I'll grant that the former
is marginally more readable, but only in the most generous, liberal
sense.

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.

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.

-Sara