Hi! > There is the following example in the RFC: > > // only values are compared > $a = (object) ["a" => "b"]; > $b = (object) ["b" => "b"]; > echo $a <=> $b; // 0 > > But the actual result is currently 1, not 0.
Ahh, I see. I think it's the mistake in the RFC. These objects are not equal, so <=> can not return 0. These objects are compared as hashtables (see zend_hash_compare), since $a has key "a" and $b does not, comparison returns 1. Since objects by default are not well-ordered, comparison does not follow the rules of order, i.e. it may happen that both $a > $b and $b > $a. That's how compare_function works and always worked, and <=> is just a call to that function. > When there is no "right" value, why not raising E_NOTICE at least. It I'm not a big fan of throwing too many notices. They are usually not very helpful an din this case it would be not easy to distinguish between intentional and unintentional use. > appears to me that returning 1 (as "undefined") without further notice > is too misleading, as it suggests that $a is greater than $b, but that > is not true: ($a > $b === false). $a > $b being false is an artifact of how ">" works in the engine - $a > $b is essentially ($b < $a). Since in this case both $a > $b and $b > $a, the result of ($b < $a) is false. That's what you get when you compare non-well-ordered things... -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
