Re: [RFC] Spaceship operator RFC

From: Date: Sun, 19 Apr 2015 23:50:22 +0000
Subject: Re: [RFC] Spaceship operator RFC
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-85875@lists.php.net to get a copy of this message
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 smalyshev@gmail.com

« previous php.internals (#85875) next »