Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <54C18C01.9090907@garfieldtech.com>
Date: Thu, 22 Jan 2015 17:47:13 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <53F8A1FF-C809-4DDF-9C6F-6916C3E4F044@ajf.me> <CAF+90c_kkD0xb_1=W=1bt00LfbXaN+JAn=kd7=MGmiFu_dTWXg@mail.gmail.com> <3251D635-D97C-4738-B537-935A6CC21E19@ajf.me> <54C17E2B.80708@garfieldtech.com> <73BC4206-BEA9-4416-BBB6-F6F99D9A8623@ajf.me>
In-Reply-To: <73BC4206-BEA9-4416-BBB6-F6F99D9A8623@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator
From: larry@garfieldtech.com (Larry Garfield)

On 01/22/2015 05:39 PM, Andrea Faulds wrote:
> Hi Larry,
>
>> On 22 Jan 2015, at 22:48, Larry Garfield <larry@garfieldtech.com> wrote:
>>
>> This looks potentially quite useful, especially for multi-stage comparisons as you note.  Mainly it would mean I don't have to remember which direction is positive or negative, as I can never get that right without looking it up. :-)
> Glad you like it. I, too, sometimes have trouble remembering what direction it goes in.
>
>> The examples say nothing about mixing types, though.  Eg, what would these return:
>>
>> return 0 <=> "0"
>>
>> return "" <=> 0
>>
>> return 1 <=> [1, 2, 3]
>>
>> Ignoring object property names and going by the order of the property definition seems like asking for trouble, too.
>>
>> There may be easy logical answers to the above given PHP's existing type juggling, but they should be called out explicitly in both the RFC and in any subsequent documentation.
> The behaviour would be the same as the current <, <=, ==, >= and > operators. If > currently returns TRUE, then it is 1, if == currently returns TRUE, then it is 0, and if < currently returns TRUE, then it is -1. Despite all the ridiculousness of our existing comparison rules, apparently <, == and > returning TRUE are mutually exclusive, thank goodness.
>
> I don’t really want to cover this behaviour in the RFC, because explaining it in full is a considerable effort and the rules it uses are not new, they are the ones PHP already uses. The behaviour for arrays is perhaps a little odd, but that is our existing behaviour, and I’d rather not introduce inconsistency by making <=> use different rules to the other operators.
>
> I agree, however, that documentation for this feature should mention the behaviour, possibly just linking to our existing documentation on type juggling.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/

Assuming it's accurate and I'm understanding you correctly, I think the 
following would be a sufficient statement for the RFC:

-----
The behavior of this operator with mixed types is such that the 
following two snippets produce the exact same result in all cases:

return $a <=> $b;

if ($a > $b) {
   return -1;
}
elseif ($a < $b) {
   return 1;
}
else {
   return 0;
}
-----

Or maybe that's implicit in the existing link, I'm not sure.  (Now that 
I read it over again.)  Basically, in order to understand the more 
esoteric type juggling that may occur you'd need to mentally expand it 
to its "uncompressed form", for which the rules are already defined (if 
possibly quirky in some cases).

--Larry Garfield