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
