Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKC-LS1tJXTA_H79rhu98GC1UnHBXCUry0_eJOzTjnXZHY7Dwg@mail.gmail.com>
References: <CAKC-LS2iLjXHbVPAuk4J_uN0d1syc1-oxgUmwVS257uX5s1bdA@mail.gmail.com>
 <CAObuZdtOdgp54_9M5=tfGBChFn4gc+GKNrOxConcM23FSD6PUw@mail.gmail.com>
 <CANUQDCh5inZjeBusG0Joz425zHtXYpExxFsMit7DtU=9uV71=g@mail.gmail.com>
 <CAEsg9X3frqCCiwmiiMKr0SO577X8PC21B0PSpR4Q6NL_hOwgJA@mail.gmail.com>
 <CANUQDChrXRXAhy37msW13uYUJNzuxuJixrd0a8Uop9nWQ=O2kQ@mail.gmail.com>
 <CADqTB_gmgU8ax-zKCV2t0ecsaZjijS-U37UL0hhp4JFK=VsSQw@mail.gmail.com> <CAKC-LS1tJXTA_H79rhu98GC1UnHBXCUry0_eJOzTjnXZHY7Dwg@mail.gmail.com>
Date: Mon, 5 Sep 2016 00:35:39 -0700
Message-ID: <CAKC-LS0fDgR4Dr4TzcfQsFcg2hSn=FK1+U7y1eO6yTVKwmNSiA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: Niklas Keller <me@kelunik.com>, David Rodrigues <david.proweb@gmail.com>, 
	Ryan Pallas <derokorian@gmail.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1143ad4e5c783d053bbdbac3
Subject: Re: [PHP-DEV] optionally return class name from gettype
From: abacaphiliac@gmail.com (Timothy Younger)

--001a1143ad4e5c783d053bbdbac3
Content-Type: text/plain; charset=UTF-8

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.
>>>
>>
>>
>

--001a1143ad4e5c783d053bbdbac3--