It's not really a bug fix, as the document for is_a() never said it
would support 'mixed' first argument. (is_subclass_of is different, it
currently says mixed as the first argument). If it needed fixing, then
support for strings should have been removed, rather than added.
The problem I have is that this 'feature' is not really that usefull, to
anyone AFAIKS. (why would you realistically want to do that kind of
check?) and if you really did need to do such a test, there are other
trivial ways to do it already (which work across versions).
I know it's reusing code at the backend, but it's a trivial change to
remove the BC break, and it does not break anything else. (nobody would
have used it that way yet..).
Regards
Alan
On Wednesday, August 24, 2011 06:43 PM, Zeev Suraski wrote:
I think there are two ways to look at it:
- As a new feature. If I understand you correctly, the fact that beforehand
is_a() was documented to only return TRUE in case the first argument was an
instance of the second argument, means that if we do anything beyond that -
e.g. support strings as the first argument - this means we break compatibility
(please correct me if I misunderstood). IMHO that's not a realistic way to
look at retaining compatibility, and I'm saying that as someone who's almost
religious about maintain compatibility. With that view of the world, almost
every bug fix and literally every feature we add - breaks compatibility.
- As a bug fix. Strings were supported even before this change, but they weren't working properly
or consistently with the way classes work everywhere else in PHP. That was fixed. Just so that we
feel good about ourselves, we also changed undocumented behavior. In case it's not clear, a
situation where is_a("bar", "foo") returns FALSE, even though bar extends foo,
but bar simply doesn't happen to be loaded in memory at the time of the call - can lead to very
real world bugs.
Zeev
-----Original Message-----
From: a...@akbkhome.com [mailto:a...@akbkhome.com]
Sent: Wednesday, August 24, 2011 12:37 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
Since when has changing documented behaviour and breaking a large
number of applications been acceptable? (Well, happens occasionally by
accident ..)
This was a 'feature change' to is_a(), it was documented as _only_ returning
'TRUE' when an object was passed as the first object and it was an instance of
that...
I did read through the previous posts, (just caught up the other day), it looks
like if anybody really need to do what this new feature provides, (which is
probably very rare), then
$left == $right || is_subclass_of($left,$right)
should work fine without breaking any code.
Regards
Alan
On Wednesday, August 24, 2011 03:44 PM, Ferenc Kovacs wrote:
On Wed, Aug 24, 2011 at 3:57 AM,
a...@akbkhome.com<a...@akbkhome.com> wrote:
It might have been better to have waited for the is_a() fix to get
sorted out.. - It's a very annoying BC break (changes the documented
behaviour), and now it means we need 4.3.9 in a few more days.
Let me know if you need help testing / applying etc..
from what I understand, this won't be changed, as the current behavior
is correct, the old was a bug:
as Stas pointed out:
"Not a bug. $var is interpreted as a class name. To know if one class
extends another, the class in question (first one) should be loaded.
There's no need to load the second one since if it's unknown nothing
can be instance of it and existing classes can not extend it."
if you used this previously
from Dmitry:
"Before the patch, is_a() didn't accept string as the first argument
at all, so it always returned "false" and never triggered
__autoload(). The proposed patch didn't revert to original behavior.
It just disables autoloading and may lead to wrong result.
class a {}
class b extends a {}
var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true
I would say that the old behaviour was wrong, especially because
"instanceof" and is_subclass_of() already implemented support for
string arguments."
so your example was bogus, as passing a non-object as a first
parameter wasn't supported (see http://php.net/is_a) so your code
example depends on an undefined behavior and results in a bogus result
(is_a() alwas returned false if you passed a non-object)
so in a way it is really a BC, but I think that this change is really a bugfix.
--
PHP Internals - PHP Runtime Development Mailing List 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
