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

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 > <mailto:bwoebi@php.net>> wrote: > bwoebi Thu, 22 Oct 2015 01:41:30 +0000 > > Revision: �0J� > �a����g��http://svn.php.net/viewvc?view=revision&revision=338015 > <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 > <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. Bob