On 2011-08-25, "firstname.lastname@example.org" wrote:
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.
Please don't generalize based on your own opinions and use cases. I am a
long time PEAR user (and contributor), and I actually agree with the
The reporter of the issue that started this all is a colleague of mine,
Ralph Schindler, and we discussed it in June along with David Zuilke,
who had run into similar issues we had (as well as discussed it with
others in other projects). It's not an isolated request; there are many
who find the current behavior of is_a() (pre-5.3.7) incoherent for
modern PHP usage.
Basically, in our case, we were building a DI container. To keep the DI
container light-weight, you create definitions that utilize string class
names. In order to determine what injections need to be made, you need
to introspect the class a little -- and this is where is_a() vs
is_subclass_of() vs instanceof comes into play. The latter two _require_
an object instance -- which we may not yet be ready to provide (we may
be trying to determine what to inject into the constructor). is_a() does
_not_ require an object instance... but prior to 5.3.7 was unable to
test against inherited behavior. As such, the only fallback is the much
more expensive Reflection API.
Having is_a() work properly with string class names and checking the
inheritance hierarchy is a huge improvement, keeps it semantically
consistent with the rest of the language, and provides capabilities
is_subclass_of() cannot (as it cannot check against strings).
I think I'll leave it as
a) no bug was ever reported on the previous behaviour.
False -- others in this thread have pointed it out, and I alluded to the
report Ralph issued earlier.
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
c) is_a() was introduced by sebastian (2002) and kept this intended
d) when andrey (2004) proposed the change to accepts strings on
is_subclass_of, he deliberately maintained the existing behaviour for
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
On Thursday, August 25, 2011 09:10 AM, Stas Malyshev wrote:
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.
Matthew Weier O'Phinney
Project Lead | email@example.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc