Alan, I think this feature can certainly be useful, but either way, but again, unless I'm misunderstanding you - you're defining new functionality (support for new types of a first argument) as a BC break. I don't think it's realistic to look at it this way.
And I do think that it's useful, assuming you don't have typos and ask about non-existent classes, or have a broken autoloader - this will work as expected and return true/false properly. Zeev > -----Original Message----- > From: a...@akbkhome.com [mailto:a...@akbkhome.com] > Sent: Wednesday, August 24, 2011 2:35 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.3.8 Released! > > 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
