Well, I have to admit this is mighty convincing :) Wasn't aware of this use-case. Falls under
the category of mass breakage I guess.
Zeev
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, August 24, 2011 3:39 PM
> To: Zeev Suraski; [email protected]
> Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
>
> " If it's a clear bug, which IMHO this is_a() issue was - then unless we're
> looking at code breakage at massive scale, it should be fixed. "
>
> mmh.. how much breakage did you want.
>
> PEAR::isError is basically is_a($input, 'PEAR_Error'); it's been like that for
> > 8
> years....
>
> google search for PEAR::isError shows 16,600 matches..
>
> http://www.google.com/codesearch#search/&q=PEAR::isError%20lang:php&
> type=cs
> <http://www.google.com/codesearch#search/&q=PEAR::isError%20lang:php
> &type=cs>
>
> for is_a you get 149K. and this is only public code...
>
> It's big... Luckily quite a few people are on holiday this month and will not
> upgrade too soon.
>
> Regards
> Alan
>
>
>
> On Wednesday, August 24, 2011 08:22 PM, Zeev Suraski wrote:
> >
> > It has nothing to do with security (criticality is subjective so I'm leaving it
> aside). The 3 bugs I mentioned (2 from 5.3.7 and one imaginary) have nothing
> to do with security, and yet we fixed them (or would have fixed them), despite
> the potential for people out there relying on the old behavior. It boils down to
> evaluating the severity of the bug and the likelihood that it'll break code. If it's
> a clear bug, which IMHO this is_a() issue was - then unless we're looking at
> code breakage at massive scale, it should be fixed.
> >
> > Again, I'm almost religious about retaining compatibility (even across major
> versions), but if we had a piece of code that was returning clearly the wrong
> value, we can't ignore it because some (my guess very few but who knows)
> relied on this behavior.
> >
> > Zeev
> >