Hi everyone,
With no further discussion and no objection to start voting on this RFC, I
would like to move forward with the vote, which requires a 2/3 majority to
pass.
RFC: https://wiki.php.net/rfc/object-comparison
Discussions:
- https://externals.io/message/102337
https://externals.io/message/102389 (June 21) - https://externals.io/message/102473 (June 26)
The vote will be open until 2018-07-16.
Thank you,
Rudi
Apologies for that middle discussion link, it was a bad hyperlink from a
bad paste if you look at source.
Here are the correct ones:
Discussion:
On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen rudolf.theunissen@gmail.com
wrote:
Hi everyone,
With no further discussion and no objection to start voting on this RFC, I
would like to move forward with the vote, which requires a 2/3 majority to
pass.RFC: https://wiki.php.net/rfc/object-comparison
Discussions:
- https://externals.io/message/102337
https://externals.io/message/102389 (June 21)- https://externals.io/message/102473 (June 26)
The vote will be open until 2018-07-16.
Thank you,
Rudi
Heya!
Just some background on my -1 vote:
- the
==operator is already riddled with edge cases and complexity,
and it is overall advisable to stay away from it - comparison of value objects already works correctly with
==(if we
don't consider edge cases like'0.' == '0.0') - the suggested approach is to add more interface-less reserved/magic
methods: anEqand anOrdclass would have solved this much more
elegantly and with clear type declarations that can be re-used in userland.
With this patch, we have to rely onmethod_exists()instead. - It would also be much clearer to enforce that
Ord extends Eq, rather
than adding implicit "sorting implies equality" rules - "the methods are not restricted to instances of the same class" - this
is something I disagree with, but we lack the type system facilities to
declare the variance of theEqandOrdoperations for a specific class.
Marco Pivetta
On Mon, Jul 9, 2018 at 8:57 PM, Rudolf Theunissen <
rudolf.theunissen@gmail.com> wrote:
Apologies for that middle discussion link, it was a bad hyperlink from a
bad paste if you look at source.Here are the correct ones:
Discussion:
On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen <
rudolf.theunissen@gmail.com>
wrote:Hi everyone,
With no further discussion and no objection to start voting on this RFC,
I
would like to move forward with the vote, which requires a 2/3 majority
to
pass.RFC: https://wiki.php.net/rfc/object-comparison
Discussions:
- https://externals.io/message/102337
https://externals.io/message/102389 (June 21)- https://externals.io/message/102473 (June 26)
The vote will be open until 2018-07-16.
Thank you,
Rudi
Thanks for explaining your vote Marco.
I realise it's probably too late but I'd like to respond anyway.
- I was hoping that this proposal would reduce those edge cases and make
==on objects something useful. - That's true, but there are so many gotchas with the current behaviour
that I wouldn't say it works well. Also no strict comparison. - We shouldn't need to ever use
method_exists()? Everything can be
compared, so tests for implementation are effectively useless. If this is
not the case in the future we can introduce interfaces for Comparable and
Equatable that abstract and implied by the presence of the methods (Golang
style). I don't foresee this to ever happen though. - "Equal ordering implies equality" is primarily to keep consistent with
current behaviour - PHP doesn't treat them as separate things today. - This was a difficult trade-off between flexibility and consistency. I
opted for a wider approach that can be narrowed later if we really want to.
Happy to discuss further.
Rudi
Heya!
Just some background on my -1 vote:
- the
==operator is already riddled with edge cases and complexity,
and it is overall advisable to stay away from it- comparison of value objects already works correctly with
==(if we
don't consider edge cases like'0.' == '0.0')- the suggested approach is to add more interface-less reserved/magic
methods: anEqand anOrdclass would have solved this much more
elegantly and with clear type declarations that can be re-used in userland.
With this patch, we have to rely onmethod_exists()instead.- It would also be much clearer to enforce that
Ord extends Eq, rather
than adding implicit "sorting implies equality" rules- "the methods are not restricted to instances of the same class" - this
is something I disagree with, but we lack the type system facilities to
declare the variance of theEqandOrdoperations for a specific class.Marco Pivetta
On Mon, Jul 9, 2018 at 8:57 PM, Rudolf Theunissen <
rudolf.theunissen@gmail.com> wrote:Apologies for that middle discussion link, it was a bad hyperlink from a
bad paste if you look at source.Here are the correct ones:
Discussion:
On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen <
rudolf.theunissen@gmail.com>
wrote:Hi everyone,
With no further discussion and no objection to start voting on this
RFC, I
would like to move forward with the vote, which requires a 2/3 majority
to
pass.RFC: https://wiki.php.net/rfc/object-comparison
Discussions:
- https://externals.io/message/102337
https://externals.io/message/102389 (June 21)- https://externals.io/message/102473 (June 26)
The vote will be open until 2018-07-16.
Thank you,
Rudi
Hi everyone,
I had a chat with Levi yesterday about the operator overloading side of
this RFC, and I'd like to try explain it as clearly as I can so that there
is no confusion.
Using <=> spaceship operator as an example, the operator is like a pointer
that references the internal compare_function. When you use the operator,
it calls that function, which in turn does comparison tests and eventually
calls object handlers when comparing objects. This RFC is not suggesting
that we change the pointer of the operator, but instead adjust the
behaviour of compare_function, which the operator already points to.
Implementing __compareTo does affect the behaviour of the operator, but
it doesn't overload it. If in the future we wanted to add proper operator
overloading, there would be a function like __spaceship that directly
overloads the operator to change its pointer to something else. If this was
to happen, __compareTo would still be used by compare_function, and
used internally when sorting or searching. I realise that the behaviour of
the operator can be changed with __compareTo, and is therefore no
different to operator overloading, but that's not how we should look at
this. The reason why <=> normalises to -1,0,1 isn't because the operator
dictates that - it's compare_function that does that, which is what the
operator points to by default.
I hope that helps to clear things up a bit. :)
On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen rudolf.theunissen@gmail.com
wrote:
Hi everyone,
With no further discussion and no objection to start voting on this RFC, I
would like to move forward with the vote, which requires a 2/3 majority to
pass.RFC: https://wiki.php.net/rfc/object-comparison
Discussions:
- https://externals.io/message/102337
https://externals.io/message/102389 (June 21)- https://externals.io/message/102473 (June 26)
The vote will be open until 2018-07-16.
Thank you,
Rudi
$x->__equals($y) && $y->__equals($z) requires that $x->__compareTo($z) be TRUE.
Typo here, it should be __equals at the end not __compareTo.
In fact, returning 0 in __compareTo for undefined natural ordering leads to all kinds of strange behaviour
If this is the case, I do not understand why you split comparison and equality, as I understood it at first the point was exactly to be able to have ordering equality without having value equality. If this leads to strangeness, why allow it?
Côme