hi, On Sun, Sep 4, 2011 at 7:52 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> So you're saying breaking BC is OK if only you can find some unaffected > applications, right? No, just like what I said for the is_a change, but it was acceptable for is_a, right? is_a actually broken many (many) apps and codes out there and it was easily identified, and it was even acceptable in a patch release. Go figure. >> There are incimoatibilities too across libmysql versions and across >> mysql servers, which are actually affecting existing codes. > > I don't know of any incompatibilities that change semantics on this level, > and anyway libmysql is beyond our control, but mysqlnd isn't. Look at the history for the mysql's bugs, plenty of them, internally or in userland. >> I cannot find any code out there relying on this test case and I very >> much doubt there is any. It is a non issue (unlike the is_a change for >> example). > > Why we're testing for functions that, as you claim, nobody ever uses? Can you please, and seriously, that's my last attempt, read my answers and see what we actually test? I never claimed that nobody uses this behavior but I cannot find any code, app or framework failing with mysqlnd. Please find one and I will change my mind. Btw, I have seen many totally pointless tests written for the sake of having a better code coverage while the code itself makes absolutely no sense or could even represent something that should not work this way in the 1st place. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
