" 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
