Re: Equality and relative ordering of objects

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 <rtheunissen@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 <rtheunissen@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 <danack@basereality.com> wrote: >> >>> On 22 June 2018 at 12:31, Rudi Theunissen <rtheunissen@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 >>> >>