On 2011-08-25, "a...@akbkhome.com" <a...@akbkhome.com> 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 change. 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 > ><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. > -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
