Everything

php

[RFC] [VOTE] User-defined object comparison

php.internals

Rudolf Theunissen

8 years ago

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

Rudolf Theunissen

8 years ago

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:*
- https://externals.io/message/102337
- https://externals.io/message/102473



On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen <rudolf.theunissen@gmail.com>
wrote:

Marco Pivetta

8 years ago

Heya!

Just some background on my -1 vote:

1. the `==` operator is already riddled with edge cases and complexity,
and it is overall advisable to stay away from it
2. comparison of value objects already works correctly with `==` (if we
don't consider edge cases like `'0.' == '0.0'`)
3. the suggested approach is to add more interface-less reserved/magic
methods: an `Eq` and an `Ord` class 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 on `method_exists()` instead.
4. It would also be much clearer to enforce that `Ord extends Eq`, rather
than adding implicit "sorting implies equality" rules
5. "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 the `Eq` and `Ord` operations for a specific class.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Mon, Jul 9, 2018 at 8:57 PM, Rudolf Theunissen <
rudolf.theunissen@gmail.com> wrote:

Rudolf Theunissen

8 years ago

Thanks for explaining your vote Marco.

I realise it's probably too late but I'd like to respond anyway.

1. I was hoping that this proposal would reduce those edge cases and make
`==` on objects something useful.
2. 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.
3. 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.
4. "Equal ordering implies equality" is primarily to keep consistent with
current behaviour - PHP doesn't treat them as separate things today.
5. 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

On Tue, 10 Jul 2018 at 05:35, Marco Pivetta <ocramius@gmail.com> wrote:

Rudolf Theunissen

8 years ago

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:

Côme Chilliet

8 years ago

> $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