Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93776
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>
References: <d9847a18-49c0-d2d0-db4e-e0d6e6685ba0@fleshgrinder.com> <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>
Date: Sat, 4 Jun 2016 21:26:25 +0200
Message-ID: <CADqTB_jDbkmbYEoyX-SE69ZSUu1-3aWRrJ9pYdE4vGn9acmegg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1143a68cbdd52c053478d0bd
Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a1143a68cbdd52c053478d0bd
Content-Type: text/plain; charset=UTF-8

> 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

It's a valid point, but not really a good argument against having it - the
same could after all be said about a lot of PHP functions.

The problem is that gettype() has numerous inconsistencies with the
language - since we can't fix gettype() without causing serious BC breaks,
I think that we do need this up-to-date function. (in fact, I would
encourage you to think about deprecating gettype, but that's probably a
discussion for another day.)

Also, this should be easy to polyfill for PHP < 7.1, correct?

It's harder to argue the same for the human-readable function, but I do
think it would be pretty great if we had this - people wouldn't think twice
about using it to generate more helpful and friendly exception messages,
and that's a good thing for the language overall. As for a third-party
dependency (such as my library) people will always think twice before
installing that *just* to produce better exception messages - I wrote the
thing, and even *I* think twice before I add that as a dependency.


On Sat, Jun 4, 2016 at 7:37 PM, Sara Golemon <pollita@php.net> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1143a68cbdd52c053478d0bd--