FAQ
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
On Mon, 2011-07-04 at 14:55 +0000, Dmitry Stogov wrote:
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/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Search Discussions

  • Johannes Schlüter at Jul 7, 2011 at 9:08 pm

    On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
    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
    On Mon, 2011-07-04 at 14:55 +0000, Dmitry Stogov wrote:
    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/)
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stas Malyshev at Jul 7, 2011 at 9:20 pm
    Hi!
    On 7/7/11 2:08 PM, Johannes Schlüter wrote:
    On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
    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
  • Daniel Convissor at Jul 8, 2011 at 1:10 pm
    Hi Folks:
    On Thu, Jul 07, 2011 at 02:20:50PM -0700, Stas Malyshev wrote:

    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
  • Ralph Schindler at Jul 8, 2011 at 2:55 pm
    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
    On 7/7/11 4:08 PM, Johannes Schlüter wrote:
    On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
    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
    On Mon, 2011-07-04 at 14:55 +0000, Dmitry Stogov wrote:
    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/)
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Dmitry Stogov at Jul 11, 2011 at 7:18 am
    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.
    On 07/08/2011 06:55 PM, Ralph Schindler wrote:
    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
    On 7/7/11 4:08 PM, Johannes Schlüter wrote:
    On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
    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
    On Mon, 2011-07-04 at 14:55 +0000, Dmitry Stogov wrote:
    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/)
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stas Malyshev at Jul 11, 2011 at 7:25 am
    Hi!
    On 7/11/11 12:18 AM, Dmitry Stogov wrote:
    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
  • Hannes Magnusson at Jul 11, 2011 at 8:17 am

    On Mon, Jul 11, 2011 at 09:25, Stas Malyshev wrote:
    Hi!
    On 7/11/11 12:18 AM, Dmitry Stogov wrote:

    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
  • Dmitry Stogov at Jul 11, 2011 at 8:21 am
    Hi Stas,
    On 07/11/2011 11:25 AM, Stas Malyshev wrote:
    Hi!
    On 7/11/11 12:18 AM, Dmitry Stogov wrote:
    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.
  • Stas Malyshev at Jul 11, 2011 at 8:18 am
    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
  • Dmitry Stogov at Jul 11, 2011 at 9:13 am
    OK. As I said I don't have strong opinion about this.
    So fell free to remove the warning.

    Thanks. Dmitry.
    On 07/11/2011 12:18 PM, Stas Malyshev wrote:
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 7, '11 at 6:27p
activeJul 11, '11 at 9:13a
posts11
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase