> I would recommend not handling overloading of comparisons in the same > proposal. Comparison is more widely useful than other overloading and has a > more complex design space (especially when it comes to accommodating objects > that can only be compared for equality/inequality for example). Comparison > may also benefit more from having an interface than the other operators.
I understand your point. There was already an RFC with an similar idea (https://wiki.php.net/rfc/comparable). I think the idea of having an comparable interface could be really useful for things like sorting algorithms (so these could sort any comparable object). The case that structures must not define an order (but can have equality) is a good point, maybe this could be solved with two interfaces Comparable (which defines the spaceship operator) and another one like Matchable or Equalable (which only defines an is_equal function). I would not split the comparison operators any further (the RFC mentioned above even suggested to overload the not equal operator) or we end up with situations, where $a!=$b is not the same as !($a==$b), which would make the code using it very difficult to understand. It is maybe reasonable to split operator and comparison overloading into different RFCs so they can be discussed separately. But if PHP decides to offer operation overloading it should also offer a possibility to compare custom objects, or the operation overloading looses some of its intended convenience (like the situation in PHP 7.0 where you could define scalar type hints, but could not allow passing null easily). > Of course there are performance concerns here, and it could in some cases be > significantly more efficient to perform an in-place modification. It is > possible to allow that while still keeping the above semantics by only > allowing an in-place modification if $a has no over users (something that we > can check in the VM). But I don't think this should be part of an initial > proposal. I agree. If there is real need for this case, it could be implemented later. > Unfortunately, this implementation goes in the wrong direction: PHP already > has full internal support for operator overloading through the do_operation > object handler. Operator overloading should be exposed to userland through > that handler as well. I have seen this mechanism too late, and I have to understand a bit more how it works exactly, but I agree that this internal operator overloading mechanism should be used. I think it should be the goal that internal and userspace classes should appear the same to the user in points of the operator overloading, so an user can just call for example parent::__add() if he is extending a PHP class (e.g. Carbon does that for the datetime class). I will try to build an implementation using the do_operation handler, when I have time. > Thanks for working on this :) I think overloaded operators are a reasonable > addition to the language at this point. I think the main concern people tend > to have in this area is that operator overloading is going to be abused (see > for example << in C++). There are many very good use-cases for operator > overloading though (as mentioned, vector/matrix calculations, complex, > rationals, money, ...) Some of those are not common in PHP, but maybe the > lack of operator overloading is part of the problem there ;) Ultimately we cannot really control how people will end up using the operation overloading, but in my opinion the benefits outweighs the drawbacks (also hopefully nobody would be insane enough to replace the print function with << ;) ). With FFI-bindings it would be possible to build cool math/calculation libraries (similar to numpy in python), that can be accessed easily via PHP and does big calculations in native speed. I don’t think PHP will become an scientific used language like python, but sometimes some higher math function in PHP could be helpful. Also at least the handling of money values is quite common in web applications. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
