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
