Backward Compatibility RFC - was Re: [PHP-DEV] Re: is_a() - again - a better fix

From: Date: Sun, 25 Sep 2011 02:00:40 +0000
Subject: Backward Compatibility RFC - was Re: [PHP-DEV] Re: is_a() - again - a better fix
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  Groups: php.internals 
Request: Send a blank email to internals+get-55624@lists.php.net to get a copy of this message
Obviously I'd be keen to see this fix applied to 5.4 as the standard use case for is_a() is mixed return testing as '$x instanceof "somestring"' does not work. I've drafted up a BC RFC, if anyone want to contribute - feel free to edit.. https://wiki.php.net/rfc/backwards_compatibility? The "ideal" aim is that in future it would be better for the proposer of BC break to have a clear way to justify it rather than do so after the fact, or point to our rather long discussions. Regards Alan On Friday, September 23, 2011 06:17 PM, Pierre Joye wrote:
hi Rasmus, On Fri, Sep 23, 2011 at 12:06 PM, Rasmus Lerdorf<rasmus@lerdorf.com> wrote:
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.
We do 2) already (while we are working on increasing the amount of apps and frameworks being tested), as I was asking to revert this patch between 5.3.7 and 5.3.8 back then pointing to our tests results and numerous reports. The problem was not in the QA but in the decision process. QA should have a kind of veto power in this case to avoid arguing and still have BC breaks landing in stable releases.
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.
It is not an easy decision, I would prefer to revert it there too as it will break BC in 5.4 as well, obviously. Cheers,


« previous php.internals (#55624) next »