# [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/tests/bug53727.phpt branches/PHP_5_3/Zend/tests/is_a.phpt branches/PHP_5_3/Zend/zend_builtin_functions.c branches/PHP_5_3/ext/standard/tests/class_object/is_a_ - Thread: https://externals.io/message/53774 - Original archive: https://news-web.php.net/php.internals/53774 - Started by Pierre Joye on 2011-07-07T18:27:09+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53774 — Pierre Joye — 2011-07-07T18:27:09+00:00 URL: https://externals.io/message/53774#53774 what kind of troubles do they see? 2011/7/7 Johannes Schlüter : > Hi, > > I was told (didn't verify) that this causes lots of trouble with PEAR > and other applications. We're in final RC phase of 5.3.7. I don't think > it is critical for 5.3.7 and I wonder whether we need it for 5.3 at all. > > johannes > > > > […] > > > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #53775 — johannes@schlueters.de — 2011-07-07T21:08:46+00:00 URL: https://externals.io/message/53774#53775 · In reply to: #53774 > what kind of troubles do they see? https://pear.php.net/bugs/bug.php?id=18656 Even if the Warning is good it's questionable for 5.3, especially during RC. (note that warnings not only cause the error being reported, which can be switched off and fill logfiles but also triggers error handlers which won't expect this ...) johannes > 2011/7/7 Johannes Schlüter : > > […] --- ## #53776 — Stas Malyshev — 2011-07-07T21:20:50+00:00 URL: https://externals.io/message/53774#53776 · In reply to: #53775 Hi! > > > […] > > https://pear.php.net/bugs/bug.php?id=18656 > > Even if the Warning is good it's questionable for 5.3, especially during > RC. Yes, I had problem with it too in couple of cases, breaks some unit tests. In fact, I'm not sure why would we need such warning at all. Unknown class - return false, who cares? PHP is way too talkative anyway, which leads to a tons of boilerplate code that serve no useful purpose but to shut it up. But leaving that aside, I think 5.3 shouldn't have this additional warning this late. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53779 — Daniel Convissor — 2011-07-08T13:10:53+00:00 URL: https://externals.io/message/53774#53779 · In reply to: #53776 Hi Folks: > > In fact, I'm not sure why would we need such warning at all. Unknown > class - return false, who cares? +1 Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #53785 — Ralph Schindler — 2011-07-08T14:55:03+00:00 URL: https://externals.io/message/53774#53785 · In reply to: #53775 Oh by all means, kill the warning. The behavior is sound though (the fix for the issue reported in #53727 where a missing parent *ce would affect the is_a_impl()'s ability to correctly determine it's subtype. The question is, should we keep the warning in 5.4? I'd say no, I think false should suffice b/c it answers the question correctly: "Is NonExistentClass a subclass of SomeOtherClass": no. In that case, there's no real need for a warning. Patch for 5.3 attached, and should probably be applied to trunk and 5.4 as well if you think that is the right idea. -ralph > > > […] > > https://pear.php.net/bugs/bug.php?id=18656 > > Even if the Warning is good it's questionable for 5.3, especially during > RC. > (note that warnings not only cause the error being reported, which can > be switched off and fill logfiles but also triggers error handlers which > won't expect this ...) > > johannes > > > […] --- ## #53830 — Dmitry Stogov — 2011-07-11T07:18:15+00:00 URL: https://externals.io/message/53774#53830 · In reply to: #53785 Hi Ralph, I don't have strong opinion about your suggestion. In some cases this warning might help to find a typo, in others it may be useless, but anyway, I think that usage of undefined class name is a quite rare situation. I would prefer to keep it as is. Thanks. Dmitry. > Oh by all means, kill the warning. The behavior is sound though (the fix > for the issue reported in #53727 where a missing parent *ce would affect > the is_a_impl()'s ability to correctly determine it's subtype. > > The question is, should we keep the warning in 5.4? I'd say no, I think > false should suffice b/c it answers the question correctly: "Is > NonExistentClass a subclass of SomeOtherClass": no. In that case, > there's no real need for a warning. > > Patch for 5.3 attached, and should probably be applied to trunk and 5.4 > as well if you think that is the right idea. > > -ralph > > > > […] --- ## #53831 — Stas Malyshev — 2011-07-11T07:25:54+00:00 URL: https://externals.io/message/53774#53831 · In reply to: #53830 Hi! > Hi Ralph, > > I don't have strong opinion about your suggestion. > > In some cases this warning might help to find a typo, in others it may > be useless, but anyway, I think that usage of undefined class name is a > quite rare situation. I would prefer to keep it as is. It's not as rare, if people use is_a the same way as instanceof. Example I've seen recently - suppose you've got a method that receives either instance of an object or it's ID, something like this: function process($obj) { if(!is_a($obj, "MyClass") { $obj = new MyClass($obj); } // process $obj } Here you've got a new warning. Of course, you could do just $obj instanceof MyClass, but it's a very subtle distinction which many people miss. So the thing here is not that $obj has unknown class name - it's not even a class name at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53836 — Dmitry Stogov — 2011-07-11T07:54:49+00:00 URL: https://externals.io/message/53774#53836 · In reply to: #53831 Hi Stas, > Hi! > > > > […] > > It's not as rare, if people use is_a the same way as instanceof. Example > I've seen recently - suppose you've got a method that receives either > instance of an object or it's ID, something like this: > > function process($obj) > { > if(!is_a($obj, "MyClass") { > $obj = new MyClass($obj); > } > // process $obj > } > > Here you've got a new warning. Of course, you could do just $obj > instanceof MyClass, but it's a very subtle distinction which many people > miss. So the thing here is not that $obj has unknown class name - it's > not even a class name at all. > That warning might be only emitted if the first operand is a name of non existing class. is_a("NonExistingClass", "MyClass"); I think this warning may make sense. :) Thanks. Dmitry. --- ## #53834 — Hannes Magnusson — 2011-07-11T08:17:27+00:00 URL: https://externals.io/message/53774#53834 · In reply to: #53831 > Hi! > > > > […] > > It's not as rare, if people use is_a the same way as instanceof. Example > I've seen recently - suppose you've got a method that receives either > instance of an object or it's ID, something like this: > > function process($obj) > { >  if(!is_a($obj, "MyClass") { >     $obj = new MyClass($obj); >  } >  // process $obj > } > > Here you've got a new warning. Of course, you could do just $obj instanceof > MyClass, but it's a very subtle distinction which many people miss. So the > thing here is not that $obj has unknown class name - it's not even a class > name at all. Isn't this exactly why `is_a()` was un-deprecated in the firstplace? Getting warnings from `is_a()` would be very weird. -Hannes --- ## #53835 — Stas Malyshev — 2011-07-11T08:18:16+00:00 URL: https://externals.io/message/53774#53835 · In reply to: #53836 Hi! > That warning might be only emitted if the first operand is a name of non > existing class. > > is_a("NonExistingClass", "MyClass"); I think you've missed my point. The point was people use this to check if first argument is an instance of a certain class or something else - and "something else" may not be a class name at all, just random string that they'll use later. > I think this warning may make sense. :) I disagree, if you look at how people are using is_a on Google's codesearch, you'll see that many use it in the same manner as instanceof. In this case, the warning is useless since the first argument is not meant to be class name, so it's no use to warn that it is not - it does not add any information and does not expose any bug. Here's an example of PEAR code: function isError($data, $code = null) { if (!is_a($data, 'PEAR_Error')) { return false; } if (is_null($code)) { return true; } elseif (is_string($code)) { return $data->getMessage() == $code; } return $data->getCode() == $code; } } I'm sure there is more code like that out there. And in such code, producing a warning has no other result but make people to add useless checks that have no other purpose but avoid warnings and annoy them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53847 — Dmitry Stogov — 2011-07-11T09:13:12+00:00 URL: https://externals.io/message/53774#53847 · In reply to: #53835 OK. As I said I don't have strong opinion about this. So fell free to remove the warning. Thanks. Dmitry. > Hi! > > > […] > > I think you've missed my point. The point was people use this to check > if first argument is an instance of a certain class or something else - > and "something else" may not be a class name at all, just random string > that they'll use later. > > > […] > > I disagree, if you look at how people are using is_a on Google's > codesearch, you'll see that many use it in the same manner as > instanceof. In this case, the warning is useless since the first > argument is not meant to be class name, so it's no use to warn that it > is not - it does not add any information and does not expose any bug. > Here's an example of PEAR code: > > function isError($data, $code = null) > { > if (!is_a($data, 'PEAR_Error')) { > return false; > } > > if (is_null($code)) { > return true; > } elseif (is_string($code)) { > return $data->getMessage() == $code; > } > > return $data->getCode() == $code; > } > } > > I'm sure there is more code like that out there. And in such code, > producing a warning has no other result but make people to add useless > checks that have no other purpose but avoid warnings and annoy them.