Edit report at https://bugs.php.net/bug.php?id=55475&edit=1
ID: 55475
User updated by: mads at gartneriet dot dk
Reported by: mads at gartneriet dot dk
Summary: is_a() triggers autoloader
Status: Assigned
Type: Bug
Package: Scripting Engine problem
PHP Version: 5.3.7
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
Maybe not a bug, but it is behaving different ind 5.3.7 than in the previous
versions, which makes some of the code from PEAR that i use, give errors.
Previous Comments:
------------------------------------------------------------------------
[2011-08-22 18:36:59] s...@php.net
This is not a bug. If first argument is a string, it is interpreted as a class
name and autoloader is called for it. Actually, IIRC, one the reasons why is_a
was
un-deprecated is that it can work with strings.
------------------------------------------------------------------------
[2011-08-22 15:46:05] johan...@php.net
is_a()'s first argument is documented to be an object. If called with a string,
following the documentation, I would actually expect a "Warning: is_a() expects
parameter 1 to be object, string given" and return NULL.
That aside and looking at the actual behavior: Previously is_a() could be used
to check whether the parameter is an object AND of a specific type in one go.
This can't be done anymore. In $a = "test"; is_a($a, "foo"); test might be an
existing class and might be of type foo. Now people have to do is_object() &&
is_a().
I don't like having such behavior change in bug fix versions as I don't like
going back and forth which is annoying for documentation and confusing for
users. I would love to keep it out of 5.3.8 to have that as low risk quick
release for the hash issue. Which means a rollback to the old way is even
harder to do. (two versions with the new behavior out)
------------------------------------------------------------------------
[2011-08-22 14:49:31] col...@php.net
Well, we have 3 options here:
1) keep it like it is since 5.3.7
2) reverting it to how it worked before 5.3.7
3) change it even more to not use autoload, so that it neither works like
<5.3.6 nor 5.3.7
Apparently through your proposed fix you're advocating for (3). If so, I can't
see how it would improve the situation in
any way.
Personally, given that the BC change is minimal, and that we're only adding
functionality, (1) seems fine.
Correct code existing before 5.3.6 will work just fine anyway.
------------------------------------------------------------------------
[2011-08-22 14:44:18] ka...@php.net
... the behaviour I'm talking about is obvious the return value and the fact
that the autoloader now is called.
------------------------------------------------------------------------
[2011-08-22 14:40:46] ka...@php.net
I'm talking about the usual procedure we have about changing behaviour, a
function suddenly returns the oppersite of what it used to in the middle of a
stable series is very unlike to do, even for PHP.
I knnow it went from not working to working, but I don't on the fact that such
a commonly used function will change behaviour like that. What we should do is
to make a big fat warning in the migration guide for 5.3.x -> 5.4.x about it,
and in the manual.
It would be the same if we changed substr() to be case insensitive in the
middle of a release series, lets just not venture in such dark corners.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55475
--
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
