On Wed, Aug 24, 2011 at 12:43 PM, Zeev Suraski <z...@zend.com> 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.
No matter what it is or how it is defined by us, it breaks existing
code and that should be avoided in bug fixes releases like 5.3.7/8.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
