Re: Equality and relative ordering of objects

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