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
go forward. the patch looks fine.
Thanks. Dmitry.
On Tue, Feb 17, 2015 at 5:47 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
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
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
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
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
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
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. :)
<snip>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.
$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
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
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. :)
<snip>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.$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 Silvappasindud@gmail.com ppasindud@gmail.com
Found something else today
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
PasinduOn 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. :)
<snip>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.$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 Silvappasindud@gmail.com ppasindud@gmail.com
--
Pasindu De Silvappasindud@gmail.com ppasindud@gmail.com
Hi!
Found something else today
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
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
Hi Guys
Something changed between alpha 1 and 2.
echo [1, 2, 3] <=> []; // gives the expected result 1 and not 3
Guess the documentation should be changed back.
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
--
Pasindu De Silvappasindud@gmail.com ppasindud@gmail.com
Pasindu De Silva wrote:
Something changed between alpha 1 and 2.
echo [1, 2, 3] <=> []; // gives the expected result 1 and not 3
Guess the documentation should be changed back.
I suggest to leave the documentation as it is. It is not wrong, the
guarantee to yield negative, positive or zero is usually sufficient, and
there is at least one code path using memcmp()[1] that is not guaranteed
to return -1, 1 or 0.
[1] http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_hash.c#2241
--
Christoph M. Becker