Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] [VOTE] User-defined object comparison

Posted by Rudolf Theunissen 
Rudolf Theunissen
[PHP-DEV] [RFC] [VOTE] User-defined object comparison
July 09, 2018 08:00PM
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
[PHP-DEV] Re: [RFC] [VOTE] User-defined object comparison
July 09, 2018 09:00PM
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 <[email protected]>
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:

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 <
[email protected]> 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:*
> - https://externals.io/message/102337
> - https://externals.io/message/102473
>
>
>
> On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen <
> [email protected]>
> 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
> >
> >
>
Rudolf Theunissen
Re: [PHP-DEV] Re: [RFC] [VOTE] User-defined object comparison
July 10, 2018 04:40PM
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 <[email protected]> wrote:

> 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 <
> [email protected]> 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:*
>> - https://externals.io/message/102337
>> - https://externals.io/message/102473
>>
>>
>>
>> On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen <
>> [email protected]>
>> 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
>> >
>> >
>>
>
>
Rudolf Theunissen
[PHP-DEV] Re: [RFC] [VOTE] User-defined object comparison
July 10, 2018 04:50PM
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 <[email protected]>
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
>
>
Côme Chilliet
Re: [PHP-DEV] [RFC] [VOTE] User-defined object comparison
July 11, 2018 10:10AM
> $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
Sorry, only registered users may post in this forum.

Click here to login