Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54907
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender)
Message-ID: <4E558B62.1040607@akbkhome.com>
Date: Thu, 25 Aug 2011 07:38:10 +0800
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: internals@lists.php.net
References: <1314115682.2635.98.camel@guybrush> <4E545A6C.60704@akbkhome.com> <CAH-PCH5jyEQZvwgqxkUpqN7a-VUc+nYt=_ixFQ1si64xxMBw4A@mail.gmail.com> <4E54C658.6070209@akbkhome.com> <887FE7CFF6F8DE4BB3A9535F53AFD06A495AAA2F@il-ex2.zend.net> <CAEZPtU4TQ_-FnrqosWfLx8xvQvgtPi2BnhkV3o=J43056Lxoeg@mail.gmail.com> <887FE7CFF6F8DE4BB3A9535F53AFD06A495AAE17@il-ex2.zend.net> <CAEZPtU5Hy6rqbj0DMVg+HhJ2yMoSA2O4ErNpwbe0JuKc0t=jrw@mail.gmail.com> <887FE7CFF6F8DE4BB3A9535F53AFD06A495AB00F@il-ex2.zend.net> <CAEZPtU7MLoH=vQ2S12keYtPtoQT9fDb9YLQrF4qOSU=iA0M+nw@mail.gmail.com> <887FE7CFF6F8DE4BB3A9535F53AFD06A495AB153@il-ex2.zend.net> <4E54F0D6.9030005@akbkhome.com>	<4E552E46.6070405@sugarcrm.com> <4E5562E1.3070005@lsces.co.uk> <CAH-PCH6ynedENVL4h=VRA9cEzV5YULcfg7x3O-VkmJw_eg_0tw@mail.gmail.com> <4E556E47.3070301@sugarcrm.com>
In-Reply-To: <4E556E47.3070301@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
From: alan@akbkhome.com (Alan Knowles)

Some real history for the young ones ;)

If you go all the way back to when is_a() was introduced, it appears 
that it was done to simplify the code in PEAR::isError, which basically 
did stuff like

if is_object() and is subclass() or get_classname() == ...

So the previous behavior was very likely the 'designed' behavior. Not an 
accidental side effect, or bug.

It's use case is reasonably common when doing tests on mixed returns 
(method returns PEAR:error, object or normal value.)

So we had a situation where a reasonable number of people (eg. anyone 
who had used PEAR), had seen and expected the previous behavior.

Where as now, we have not had a single direct bug report saying this 
behavior is bad (AFAIK), yet we are going to change it to fix an unusual 
use case on is_subclass_of as they use the same backend code.

If this had been reported as a bug, or anybody on this list had actually 
been using it and had a gotcha moment, fine. but I've not heard anybody 
say that, just they think perhaps it should work a different way.

Please do not fix something that is not broken, and breaks real working 
code, just for the hell of it, even in 5.4.

Regards
Alan

On Thursday, August 25, 2011 05:33 AM, Stas Malyshev wrote:
> Hi!
>
> Thanks for providing the timeline.
>
> On 8/24/11 2:15 PM, Ferenc Kovacs wrote:
>> 5, Helgi fixed Pear in the meanwhile
>> http://svn.php.net/viewvc/pear/pear-core/tags/PEAR-1.9.5/PEAR.php?r1=313081&r2=313083&pathrev=313340 
>>
>
> This fix doesn't look good - it doesn't do what is was meant to do.
>
>> 7, Helgi reverts the Pear fix
>> http://svn.php.net/viewvc/pear/pear-core/tags/PEAR-1.9.5/PEAR.php?r1=313340&r2=313339&pathrev=313340 
>>
>
> And this should be using instanceof instead.
>
>> 8, nobody notices the meaning of this change:
>> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/Zend/zend_builtin_functions.c?r1=312904&r2=312903&pathrev=312904#l848 
>>
>> which AFAIK means that the zend_lookup_class (and hence autoloading)
>> will always be called if the first argument is a string for is_a.
>> previously it would only happen for is_subclass_of()
>
> Well, it is obvious to me that is_a() and is_subclass_of() should work 
> the same and both autoload the first argument if it's a string. 
> However, the docs have is_subclass_of() documented as accepting string 
> while is_a() is not and it worked as always returning false given 
> non-object. I think we could easily keep this behavior for 5.3 even 
> though I think relying on this is wrong (and you SHOULD fix it 
> anywhere your code relies on it, including PEAR).