> 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 <poll...@php.net> wrote: > On Sat, Jun 4, 2016 at 5:12 AM, Fleshgrinder <p...@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 > >
