Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Spaceship operator RFC »

[RFC] Spaceship operator RFC

php.internals

Stas Malyshev

11 years ago
Hi! As expected, spaceship operator RFC (https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes to 11. I'll proceed with merging it soon.
-- Stas Malyshev smalyshev@gmail.com

Dmitry Stogov

11 years ago
go forward. the patch looks fine. Thanks. Dmitry. On Tue, Feb 17, 2015 at 5:47 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Christoph Becker

11 years ago
Hi! Stanislav Malyshev wrote:
> As expected, spaceship operator RFC > (https://wiki.php.net/rfc/combined-comparison-operator) passed 43 votes > to 11. I'll proceed with merging it soon.
A discrepancy between the actual behavior of the spaceship operator and an example given in its RFC has been reported recently (bug #69466[1]). To me it appears that there is a contradiction in the RFC (see my comment on the respective report), which would have to be resolved one way or another. [1] <https://bugs.php.net/bug.php?id=69466>
-- Christoph M. Becker

Stas Malyshev

11 years ago
Hi!
> A discrepancy between the actual behavior of the spaceship operator and > an example given in its RFC has been reported recently (bug #69466[1]).
I'm not sure what the discrepancy is, could you explain?
> To me it appears that there is a contradiction in the RFC (see my > comment on the respective report), which would have to be resolved one > way or another.
I don't see the contradiction. The objects in your example are not comparable, since $a < $b and $b < $a are both not true, 1 is returned. Returning 0 would be wrong of course since these objects are not equal. In fact, there's no "right" value in this case as objects are not comparable - so the result is undefined. In this case, undefined is 1.
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

11 years ago
Hi! Stanislav Malyshev wrote:
> >> A discrepancy between the actual behavior of the spaceship operator and >> an example given in its RFC has been reported recently (bug #69466[1]). > > I'm not sure what the discrepancy is, could you explain?
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.
>> To me it appears that there is a contradiction in the RFC (see my >> comment on the respective report), which would have to be resolved one >> way or another. > > I don't see the contradiction. The objects in your example are not > comparable, since $a < $b and $b < $a are both not true, 1 is returned. > Returning 0 would be wrong of course since these objects are not equal. > In fact, there's no "right" value in this case as objects are not > comparable - so the result is undefined. In this case, undefined is 1.
When there is no "right" value, why not raising E_NOTICE at least. It 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).
-- Christoph M. Becker

Stas Malyshev

11 years ago
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

Christoph Becker

11 years ago
Hi! Stanislav Malyshev wrote:
> Ahh, I see. I think it's the mistake in the RFC. [...]
Then it is probably best to fix the RFC. :)
> 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.
<snip>
> $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...
I get your point. I suggest to amend the documentation[1] to make it clear that comparing non-well-ordered values results in undefined behavior (it might be best to treat the return value 1 in this case as implementation specific). [1] <http://php.net/manual/en/language.operators.comparison.php>
-- Christoph M. Becker

Pasindu De Silva

11 years ago
Hi Found this while trying to do the documentation, Thought the same that it was a RFC mistake, therefore didn't put any examples. Will do the necessary documentation if this is the case. +1 Pasindu On Mon, Apr 20, 2015 at 7:13 PM, Christoph Becker <cmbecker69@gmx.de> wrote:
> Hi! > > Stanislav Malyshev wrote: > > > Ahh, I see. I think it's the mistake in the RFC. [...] > > Then it is probably best to fix the RFC. :) > > > 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. > > <snip> > > > $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... > > I get your point. I suggest to amend the documentation[1] to make it > clear that comparing non-well-ordered values results in undefined > behavior (it might be best to treat the return value 1 in this case as > implementation specific). > > [1] <http://php.net/manual/en/language.operators.comparison.php> > > -- > Christoph M. Becker > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- *Pasindu De Silva**ppasindud@gmail.com <ppasindud@gmail.com>*

Pasindu De Silva

11 years ago
Found something else today http://3v4l.org/mO48q echo [1, 2, 3] <=> []; // 1 but it gives 3 On Mon, Apr 20, 2015 at 7:29 PM, Pasindu De Silva <ppasindud@gmail.com> wrote:
> Hi > Found this while trying to do the documentation, Thought the same that it > was a RFC mistake, > therefore didn't put any examples. Will do the necessary documentation if > this is the case. > > +1 > Pasindu > > > On Mon, Apr 20, 2015 at 7:13 PM, Christoph Becker <cmbecker69@gmx.de> > wrote: > >> Hi! >> >> Stanislav Malyshev wrote: >> >> > Ahh, I see. I think it's the mistake in the RFC. [...] >> >> Then it is probably best to fix the RFC. :) >> >> > 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. >> >> <snip> >> >> > $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... >> >> I get your point. I suggest to amend the documentation[1] to make it >> clear that comparing non-well-ordered values results in undefined >> behavior (it might be best to treat the return value 1 in this case as >> implementation specific). >> >> [1] <http://php.net/manual/en/language.operators.comparison.php> >> >> -- >> Christoph M. Becker >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > -- > > *Pasindu De Silva**ppasindud@gmail.com <ppasindud@gmail.com>* >
-- *Pasindu De Silva**ppasindud@gmail.com <ppasindud@gmail.com>*

Stas Malyshev

11 years ago
Hi!
> Found something else today > > http://3v4l.org/mO48q > > echo [1, 2, 3] <=> []; // 1 but it gives 3
Yeah compare_function can actually return more than 1, 0 and -1, esp. for arrays but maybe . I'm not sure if we should change this or not. It should be pretty easy to fix, just not sure why it's this way now - see zend_compare_arrays and down to zend_hash_compare.
-- Stas Malyshev smalyshev@gmail.com

Christoph Becker

11 years ago
Stanislav Malyshev wrote:
> Yeah compare_function can actually return more than 1, 0 and -1, esp. > for arrays but maybe . I'm not sure if we should change this or not. It > should be pretty easy to fix, just not sure why it's this way now - see > zend_compare_arrays and down to zend_hash_compare.
FWIW: the documentation has already been adjusted by Peter (salathe): <https://svn.php.net/viewvc?view=revision&revision=336683> <http://docs.php.net/manual/en/language.operators.comparison.php>
-- Christoph M. Becker