Re: optionally return class name from gettype

i just thought of another option. what if gettype returned the classname as a part of the "object" string, e.g. "object (point)", "object (stdClass)", "object (Exception)", etc. this would be similar to gettype's return on a closed resource: "resource (closed)": https://github.com/php/php-src/blob/master/ext/standard/type.c#L71 although, this could break consumer code. e.g. gettype($obj) === "object". maybe this option is not so good. On Mon, Sep 5, 2016 at 12:02 AM, Timothy Younger <abacaphiliac@gmail.com> wrote: > 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. >>> >> >> >