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:
This fix doesn't look good - it doesn't do what is was meant to do.
And this should be using instanceof instead.
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).