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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
