I think it's too late to do much of anything other than document the
change in a way that makes it easier for people to recognize. I spoke
to Philip about this offline and I think the two options along these
lines are:
1) Add a WARNING box which specifies the change for the function, that
a true type check for strings no longer yields FALSE
2) Update the first argument documentation from object -> mixed,
mention it has started accepting mixed as of 5.3.7, and highlight the
fact this function no longer returns FALSE when the type check (for
strings) fails.
fwiw - the pre-5.3.7 behavior was sub-optimal/broken but this is a BC
break, if you consider modifying an existing function signature a BC
break (which I'd hope most people do).
I realize the release RFC isn't live till 5.4 but I am concerned that
the continuing debate around what is and isn't a BC break, which has
taken a large chunk of this thread, will hinder the relrfc moving
forward.
- JJ
On Wed, Aug 24, 2011 at 5:50 AM, Zeev Suraski <[email protected]> wrote:
> 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
>> >
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>