Re: Re: is_a() - again - a better fix

2011/9/23 Rasmus Lerdorf <rasmus@lerdorf.com>: > On 09/23/2011 01:37 AM, Alan Knowles wrote: >> This patch adds an extra parameter 'allow_string' to is_a (default off) >> and is_subclass_of (default on) , >> >> Œj2 >> »i%†ûm³Mfhttps://bugs.php.net/patch-display.php?bug_id=55475&patch=Is_a_with_allow_string_argument_v3&revision=latest >> >> <https://bugs.php.net/patch-display.php?bug_id=55475&patch=Is_a_with_allow_string_argument_v3&revision=latest> >> >> >> It also explains why their behaviour is different. This is a clean, no >> BC break, solution. let's move on and just fix this. > > Ok, executive decision made. Patch committed. We obviously screwed up in > making this change in the 5_3 branch and since at least one distro has > held off in pushing out newer 5.3 builds in order to not break every > existing PEAR package, it is completely clear to me that this needed to > be fixed in 5.3. > > So, a couple of ideas to address cases like this in the future. > > 1. Should we work up a basic PEAR test case that we can add to our >   tests? > > 2. Maybe we should think bigger and put more focus on having large PHP >   frameworks and apps test every RC. Currently we notify them of RCs >   and just hope someone will test and report back, but that obviously >   isn't working. We need a Daniel Brown-like approach to this. Someone >   who is really annoyingly persistent and will hunt down people to >   test RCs and keep a sign-off checklist of projects that have given >   a thumbs-up on an RC. Solution 2: +1 Having a Jenkins instance which would run major framework testsuites against the different versions of PHP? > Oh, and what do we do in 5.4? Philosophically I think Dmitry's original > change was correct, but none of us realized all the code relying > (arguably incorrectly) on the original behaviour. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php