Here is a WIP implementation of `__compareTo`, with some decent tests. https://github.com/php/php-src/compare/master...rtheunissen:rt-compare-to-magic-method?diff=unified
On Fri, 22 Jun 2018 at 17:03, Rudi Theunissen <rtheunis...@php.net> wrote: > On further investigation, I'm not sure if we need both `__equals` and > `__compareTo`, > even with all the talk about contexts and the fact that an object can be > tested for > equality and not necessarily ordering as well. If we take out the > `__equals` method > and only include `__compareTo`, we can allow the user to return NULL to > indicate > that the object doesn't support the comparison that is being done. So the > return > values of `__compareTo` then becomes: > > ``` > 1: Greater than > -1: Less than > 0: Equal to, == > NULL: Unsupported, fall back to default behaviour. > ``` > In the case of an object returning NULL, we can fall back to the default > behaviour, > which is equivalent to the `compare` handler returning FAILURE, which then > falls > through to the `compare_objects` handler. > > I think this will be less confusing and much easier to implement. > > It's interesting to note that Java's `Comparable` interface considers a > 0-return > to indicate equality, where a `==` would compare references in the same > way > PHP's `===` would. So in dropping the `__equals` method, we're slightly > more > aligned with Java, even though that's not exactly the goal here. :p > > On Fri, 22 Jun 2018 at 13:55, Rudi Theunissen <rtheunis...@php.net> wrote: > >> What's the best place to override == internally? `do_operation` or a new >> object handler? >> I'd like to separate equality from compare_function.. or should we ignore >> `__equals ` >> and assume that the values are equal if `__compareTo` returns 0? >> >> Here's some context: I'm modifying `is_equal_function` to check for an >> `__equals` >> implementation if the value is an object, which I think should work, but >> it's not clear how >> an internal object (like the ds structures, for example) should override >> ==. >> >> `do_operation` seems like a good choice for this, but I wanted to check >> with you all first. >> >> >> >> On Fri, 22 Jun 2018 at 13:06, Rudi Theunissen <rtheunis...@php.net> >> wrote: >> >>> > Yes, that's the type of thing that I think needs to be included as >>> > part of the RFC. >>> > >>> > Including a list of all the (or at least the important) functions that >>> > would be affected by this RFC should be made both for clarity and so >>> > that people can think through any edge cases. >>> >>> >>> Absolutely. I was hoping to gather some thoughts and opinions first >>> while I >>> work on the implementation before I submit an official RFC. I'll make >>> sure to >>> include what you've mentioned, I completely agree. >>> >>> On Fri, 22 Jun 2018 at 11:14, Dan Ackroyd <dan...@basereality.com> >>> wrote: >>> >>>> On 22 June 2018 at 12:31, Rudi Theunissen <rtheunis...@php.net> wrote: >>>> >>>> > >>>> >> I think if you want to push the RFC forward, a really quite strong >>>> >> case needs to be made for why having it be a language level feature >>>> is >>>> >> so much better (or even at all better) than having it be implemented >>>> >> in userland. >>>> >>>> > >>>> > >>>> > 1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`, >>>> `!=` with >>>> > a userland implementation. >>>> > 2. Therefore, you won't be able to affect the internals of array >>>> functions >>>> > like `in_array`, `sort` etc. >>>> >>>> >>>> Yes, that's the type of thing that I think needs to be included as >>>> part of the RFC. >>>> >>>> Including a list of all the (or at least the important) functions that >>>> would be affected by this RFC should be made both for clarity and so >>>> that people can think through any edge cases. >>>> >>>> cheers >>>> Dan >>>> >>>
