I'm not sure it's possible to get agreement on if this is a bug or not,
you might see a bug, I just see this as a pointless change for
consistency that pretty much nobody will ever need or use.
I think I'll leave it as
a) no bug was ever reported on the previous behaviour.
b) intended "design" of is_subclass_of was originally to return false
on non-object - andrei (1999)
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=17245&r2=17272
<http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=17245&r2=17272>
c) is_a() was introduced by sebastian (2002) and kept this intended
behaviour
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=67102&r2=69234
<http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=67102&r2=69234>
d) when andrey (2004) proposed the change to accepts strings on
is_subclass_of, he deliberately maintained the existing behaviour for
is_a()
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=170604&r2=171349
<http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=170604&r2=171349>
e) is_a() has a valid use case , and is currently reasonably commonly used.
d) the new behaviour is an uncommon use case, and can be done very
easily in other ways.
BTW. we could really do with a searchable archive of php.dev +
internals... - It's pretty difficult to find out if this was ever
discussed before..
Regards
Alan
On Thursday, August 25, 2011 09:10 AM, Stas Malyshev wrote:
Hi!
On 8/24/11 4:38 PM, Alan Knowles wrote:
Some real history for the young ones ;)
I wonder who you are meaning... :)
So the previous behavior was very likely the 'designed' behavior. Not an
accidental side effect, or bug.
Bugs can be very well intentional, but if they use the language wrong
way they are bugs.
It's use case is reasonably common when doing tests on mixed returns
(method returns PEAR:error, object or normal value.)
That's when you use instanceof.
So we had a situation where a reasonable number of people (eg. anyone
who had used PEAR), had seen and expected the previous behavior.
Seeing wrong code somewhere doesn't mean it's not wrong. There's a
reason we have the manual.
Please do not fix something that is not broken, and breaks real working
code, just for the hell of it, even in 5.4.
is_a() was broken - it was returning different results from
essentially the same function is_subclass_of() for no reason at all
(no, somebody writing buggy code in PEAR using undocumented parameter
types is not a reason). The reason why we kept is_a() and not killed
it in favor of instanceof was to have it work with string arguments,
since instanceof does not. Thus, string arguments should be handled
properly. I can see how it can be argued that 5.3 is mature enough so
such changes shouldn't be there, however correct in theory. For 5.4, I
see no base for argument here.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
