On 6/4/2016 7:37 PM, Sara Golemon wrote: > On Sat, Jun 4, 2016 at 5:12 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: >> I prepared my first contribution to internals: >> > Welcome! >
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. > 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? > 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? > 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) === '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. > 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. > 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. > 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. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
