Hi everyone, I've made some changes to the RFC and the implementation today to explain some of the edge cases and combined behaviour better.
There are some issues towards the bottom of the RFC that I would really like some opinions on. They all have decisions made but are not concrete, so I'd like to know if anyone has strong opinions on them before they are considered a final part of the RFC. I'm happy with the current state but I'm very open to changing those decisions if there's a good enough reason to. See https://wiki.php.net/rfc/object-comparison#open_issues Thank you On Wed, 27 Jun 2018 at 18:53, Rudolf Theunissen <rudolf.theunis...@gmail.com> wrote: > In summary, I propose that return type constraints should be removed >> which will allow us to pursue specific operator overloading at a later >> point if we desire > > > There are no return types or parameter types. The only requirement is that > the function is public and not static. > > > On Wed, 27 Jun 2018 at 15:21, Levi Morrison <le...@php.net> wrote: > >> On Wed, Jun 27, 2018 at 12:24 PM Levi Morrison <le...@php.net> wrote: >> > >> > On Tue, Jun 26, 2018 at 5:50 PM Rudolf Theunissen >> > <rudolf.theunis...@gmail.com> wrote: >> > > >> > > Hi everyone, >> > > >> > > This is an RFC that is based on previous discussions here: >> > > https://externals.io/message/102337 >> > > >> > > RFC: https://wiki.php.net/rfc/object-comparison >> > > >> > > The implementation is tested and appears to be working as expected. :) >> > >> > I had some off-list contact with Rudi and generally have agreed with >> > these changes. >> > >> > However, there may be some value in following Python's lead. In Python >> > 2 they had a `__cmp__` magic method and in Python 3 they removed it >> > and added all of these: >> > >> > __lt__ >> > __le__ >> > __eq__ >> > __ne__ >> > __gt__ >> > __ge__ >> > >> > This permits things such as NumPy to overload < to do an element-wise >> > comparison of the members; something like this: >> > >> > np.array([1, 3, 5, 7]) < np.array([2, 1, 6, 6]) >> > // evaluates to np.array([true, false, true, false) >> > >> > If we pursue this Pythonic route then we would also need methods for + >> > - * / % etc. I do not want to derail the conversation too much, but it >> > does seem opportune to discuss operator overloading more generally. >> >> We would still need `__compareTo` if we did operator overloading >> because we have the `<=>` operator. Rudi has pointed out that because >> of this we should be able to overload individual operators at a later >> point without backwards compatibility issues if we so choose. I think >> this is true if we do not constrain the return types. >> >> In summary, I propose that return type constraints should be removed >> which will allow us to pursue specific operator overloading at a later >> point if we desire; an author can always add `: bool` or `: int` to >> their own methods if they so desire. >> >
