Re: svn: /phpdoc/en/trunk/appendices/migration70/ new-features.xml

On 22 October 2015 at 12:21, Bob Weinand <bobwei9@hotmail.com> wrote: > Hey, > > Am 22.10.2015 um 10:35 schrieb Peter Cowburn <petercowburn@gmail.com>: > > On 22 October 2015 at 02:41, Bob Weinand <bwoebi@php.net> wrote: > >> bwoebi Thu, 22 Oct 2015 01:41:30 +0000 >> >> Revision: >> http://svn.php.net/viewvc?view=revision&revision=338015 >> >> Log: >> Fix bug #70746 (Please document spaceship as returning -1 or 0 or 1) >> >> Bug: https://bugs.php.net/70746 (Verified) Please document >> spaceship as >> returning -1 or 0 or 1 >> >> Changed paths: >> U phpdoc/en/trunk/appendices/migration70/new-features.xml >> >> Modified: phpdoc/en/trunk/appendices/migration70/new-features.xml >> =================================================================== >> --- phpdoc/en/trunk/appendices/migration70/new-features.xml >> 2015-10-21 20:47:06 UTC (rev 338014) >> +++ phpdoc/en/trunk/appendices/migration70/new-features.xml >> 2015-10-22 01:41:30 UTC (rev 338015) >> @@ -144,10 +144,9 @@ >> <sect2 xml:id="migration70.new-features.spaceship-op"> >> <title>Spaceship operator</title> >> <para> >> - The spaceship operator is used for comparing two expressions. It >> returns an >> - <type>integer</type> less than, equal to, or greater than zero when >> - <varname>$a</varname> is respectively less than, equal to, or greater >> than >> - <varname>$b</varname>. Comparisons are performed according to PHP's >> usual >> + The spaceship operator is used for comparing two expressions. It >> returns -1, 0 >> + or 1 when <varname>$a</varname> is respectively less than, equal to, >> or greater >> + than <varname>$b</varname>. Comparisons are performed according to >> PHP's usual >> <link linkend="types.comparisons">type comparison rules</link>. >> > > It is my understanding that the spaceship operator isn't guaranteed to > return those values: even if it does in 99.999% of cases. Is the -1, 0 or > 1 behaviour now guaranteed and I just missed that change? If the operator > is guaranteed to return -1, 0 or 1 then great. Otherwise we should at least > mention the possibility, however small, of different values (if indeed that > is still possible). > > >> </para> >> <informalexample> >> > > The RFC is explicitly documenting it as -1, 0 and 1. > > Strictly seen, you are right, it is actually not being ensured for > object_handlers->compare_objects. But as far as I see, we also internally > expect compare_function to just return one of these three values. > I'd say, if in any case an extension returns anything else than null for > compare_objects, it's buggy and should be fixed. > … we eventually could apply an ZEND_NORMALIZE_BOOL() in source to ensure > it to 100%, if that's safer. > > For an end-user, he definitely should be able to rely on that well-defined > set of values. > Great, that all tallies up with what I expected. So, let's keep the docs are they now are. > > Bob >