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 <z...@zend.com> 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: a...@akbkhome.com [mailto:a...@akbkhome.com] >> Sent: Wednesday, August 24, 2011 3:39 PM >> To: Zeev Suraski; internals@lists.php.net >> 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
