Hi! > Yes, like I said, I am aware that the comparison function is flaky > but it is still code that has worked for 15 years so we have to be > clear about the BC break. The fact that it works up until the array
Looking at that function, I'm not sure the fact it worked is not pure luck. It is not an order function - it produces different result when parameters are switched, i.e. if you call f($a, $b) it would say $a > $b, but if you call f($b, $a) it would say $a == $b. Of course, even broken functions can produce valid results, with some luck, but I'm not sure we can guarantee non-order functions to work when order function is required. It's too bad PHP does not have <=> operator (which, along with being useful for writing functions exactly like this, has a cool name "spaceship operator" :) We have an RFC on that: https://wiki.php.net/rfc/combined-comparison-operator but it seems to be stalled. Maybe we should revive it? > gets more than 16 elements makes it a tricky one to track down for > people. With the massive volume of legacy code out there we have to > be careful with changes like this that can break existing code, even > if that code is questionable. I agree in principle, but in this case the code is not "questionable", it's wrong. If we use an order-based algorithm, the function should satisfy basic rules for order - i.e. $a == $a, if $a < $b then $b > $a, if $a > $b and $b > $c then $a > $c, etc. If it does not, I don't think we can guarantee anything here. > At the very least we need a clear note in the upgrading doc reminding > people to check all their user comparison functions. That is a good idea, knowing that the change can expose previously hidden bugs is useful. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
