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