Re: optionally return class name from gettype

thank you all for your feedback. it seems this thread is split between an optional param and a new function, so i created a new function called var_type for comparison. commit: https://github.com/abacaphiliac/php-src/commit/eca6f77bf2744c79671d1dfbb641b753503d4a1a build: https://travis-ci.org/abacaphiliac/php-src/builds/157555638 it mirrors gettype except that it returns a classname instead of the string "object". i'm not a fan of the code duplication, so i'm looking into a couple of ways to address that. the result will likely couple var_type to gettype, but that is no worse than my optional param solution. is decoupled code better than code duplication in this scenario? does comparing my commits help? how can i proceed? should i open merge requests that reference each other to see if either one is acceptable, or if they need work? should i submit an RFC that includes both commits so that there can be a vote? thanks for your time and honest feedback. On Sat, Jul 30, 2016 at 5:46 AM, Rasmus Schultz <rasmus@mindplay.dk> wrote: > I agree, an argument that essentially turns it into a different function > is not a good practice. > > Suggestions for a function-name? > > typeof() or vartype() maybe? > > > On Fri, Jul 29, 2016 at 8:17 PM, Niklas Keller <me@kelunik.com> wrote: > >> > >> > Niklas Keller wrote: >> > > I'm not sure on the boolean through, I think a new function might be >> > better. >> > >> > In this point I desagree. >> > I think that boolean is the best way, mainly to avoid a new function >> > on userland. >> > It's like an "extension" for gettype(), and make senses just extend it. >> >> >> The issue is that it's not clear what this boolean means just from reading >> the code. >> If you follow Clean Code, you shouldn't have something like that, only in >> very, very rare cases. >> > >