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.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
