what kind of troubles do they see?
2011/7/7 Johannes Schlüter johannes@schlueters.de:
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
dmitry Mon, 04 Jul 2011 14:55:39 +0000
Revision: http://svn.php.net/viewvc?view=revision&revision=312904
Log:
Fixed bug #53727 (Inconsistent behavior of is_subclass_of with interfaces)Bug: https://bugs.php.net/53727 (Assigned) Inconsistent behavior of is_subclass_of with interfaces
Changed paths:
U php/php-src/branches/PHP_5_3/NEWS
A php/php-src/branches/PHP_5_3/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_3/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c
U php/php-src/branches/PHP_5_3/ext/standard/tests/class_object/is_a_variation_001.phpt
A php/php-src/branches/PHP_5_4/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_4/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_4/Zend/zend_builtin_functions.c
U php/php-src/branches/PHP_5_4/ext/standard/tests/class_object/is_a_variation_001.phpt
A php/php-src/trunk/Zend/tests/bug53727.phpt
U php/php-src/trunk/Zend/tests/is_a.phpt
U php/php-src/trunk/Zend/zend_builtin_functions.c
U php/php-src/trunk/ext/standard/tests/class_object/is_a_variation_001.phpt--
PHP CVS Mailing List (http://www.php.net/)--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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 johannes@schlueters.de:
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
dmitry Mon, 04 Jul 2011 14:55:39 +0000
Revision: http://svn.php.net/viewvc?view=revision&revision=312904
Log:
Fixed bug #53727 (Inconsistent behavior of is_subclass_of with interfaces)Bug: https://bugs.php.net/53727 (Assigned) Inconsistent behavior of is_subclass_of with interfaces
Changed paths:
U php/php-src/branches/PHP_5_3/NEWS
A php/php-src/branches/PHP_5_3/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_3/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c
U php/php-src/branches/PHP_5_3/ext/standard/tests/class_object/is_a_variation_001.phpt
A php/php-src/branches/PHP_5_4/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_4/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_4/Zend/zend_builtin_functions.c
U php/php-src/branches/PHP_5_4/ext/standard/tests/class_object/is_a_variation_001.phpt
A php/php-src/trunk/Zend/tests/bug53727.phpt
U php/php-src/trunk/Zend/tests/is_a.phpt
U php/php-src/trunk/Zend/zend_builtin_functions.c
U php/php-src/trunk/ext/standard/tests/class_object/is_a_variation_001.phpt--
PHP CVS Mailing List (http://www.php.net/)
Hi!
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.
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
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
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
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üterjohannes@schlueters.de:
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
dmitry Mon, 04 Jul 2011 14:55:39 +0000
Revision: http://svn.php.net/viewvc?view=revision&revision=312904
Log:
Fixed bug #53727 (Inconsistent behavior of is_subclass_of with interfaces)Bug: https://bugs.php.net/53727 (Assigned) Inconsistent behavior of is_subclass_of with interfaces
Changed paths:
U php/php-src/branches/PHP_5_3/NEWS
A php/php-src/branches/PHP_5_3/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_3/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c
U php/php-src/branches/PHP_5_3/ext/standard/tests/class_object/is_a_variation_001.phpt
A php/php-src/branches/PHP_5_4/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_4/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_4/Zend/zend_builtin_functions.c
U php/php-src/branches/PHP_5_4/ext/standard/tests/class_object/is_a_variation_001.phpt
A php/php-src/trunk/Zend/tests/bug53727.phpt
U php/php-src/trunk/Zend/tests/is_a.phpt
U php/php-src/trunk/Zend/zend_builtin_functions.c
U php/php-src/trunk/ext/standard/tests/class_object/is_a_variation_001.phpt--
PHP CVS Mailing List (http://www.php.net/)
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
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üterjohannes@schlueters.de:
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
dmitry Mon, 04 Jul 2011 14:55:39 +0000
Revision: http://svn.php.net/viewvc?view=revision&revision=312904
Log:
Fixed bug #53727 (Inconsistent behavior of is_subclass_of with
interfaces)Bug: https://bugs.php.net/53727 (Assigned) Inconsistent behavior of
is_subclass_of with interfacesChanged paths:
U php/php-src/branches/PHP_5_3/NEWS
A php/php-src/branches/PHP_5_3/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_3/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c
U
php/php-src/branches/PHP_5_3/ext/standard/tests/class_object/is_a_variation_001.phptA php/php-src/branches/PHP_5_4/Zend/tests/bug53727.phpt
U php/php-src/branches/PHP_5_4/Zend/tests/is_a.phpt
U php/php-src/branches/PHP_5_4/Zend/zend_builtin_functions.c
U
php/php-src/branches/PHP_5_4/ext/standard/tests/class_object/is_a_variation_001.phptA php/php-src/trunk/Zend/tests/bug53727.phpt
U php/php-src/trunk/Zend/tests/is_a.phpt
U php/php-src/trunk/Zend/zend_builtin_functions.c
U
php/php-src/trunk/ext/standard/tests/class_object/is_a_variation_001.phpt--
PHP CVS Mailing List (http://www.php.net/)
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
Hi Stas,
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.
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.
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
OK. As I said I don't have strong opinion about this.
So fell free to remove the warning.
Thanks. Dmitry.
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.
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.
Isn't this exactly why is_a() was un-deprecated in the firstplace?
Getting warnings from is_a() would be very weird.
-Hannes