On Wed, Aug 24, 2011 at 12:43 PM, Zeev Suraski <[email protected]> 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