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