Function and operator overloading

php.internals

Terje Slettebø

6 years ago
Hi. Please excuse me if this has been discussed to death earlier. I've tried to search for it, but I've come up empty: https://www.php.net/results.php? q=function+overloading&l=en&p=all The recent discussion on operator overloading has highlighted the relationship between function overloading and operator overloading, and how having support for the former may help provide the latter. For those with experience with C++, function and operator overloading works the same way, and the only difference is that operator overloading is defined as a function of the form "operator+(...)", i.e. "operator" followed by the operator itself. I know that C++'s system for overloading is very complex (because it has something called partial ordering of functions, and it also includes templates/generics). Nevertheless, I think it could be possible to implement a subset in PHP, without all the complexity, and in this way provide a cleaner way of implementing either kind of overloading, and avoiding the "closed set" / library interaction issues mentioned in the other thread. What I have in mind is to let the parameter types of a function become part of the function name, something like this: // Function overloads function add(Money $a, Money $b): Money { ... } function add(Matrix $a, Matrix $b): Matrix { ... } // Operator overloads function operator+(Money $a, Money $b): Money { ... } function operator*(Money $a, Percentage $b); Money { ... } function operator*(Matrix $a, Matrix $b): Matrix { ... } Use: $m1 = new Money(100); $m2 = new Money(200); $p = new Percentage(10); $result = $m1 + $m2; // Money(300) $result = $m1 * $p; Money(10) I realise that including the parameter types as part of the (internal) name of a function is a major departure from the way PHP works today. However, if we are to grow PHP into the future, and continue to provide clean ways of expressing things, then maybe we should re-examine such fundamental things, where a clean interface and simplicity for the developer is more important than implementation complexity. Regards, Terje

Nikita Popov

6 years ago
On Sat, Mar 28, 2020 at 12:10 PM Terje Slettebø < terje.slettebo@sandefjordbredband.net> wrote:
> Hi. > > Please excuse me if this has been discussed to death earlier. I've tried > to search for it, but I've come up empty: > https://www.php.net/results.php? > q=function+overloading&l=en&p=all >
Yes, this has already been discussed to death. The search on php.net does not extend to the mailing list archives. You may find https://externals.io/ or https://markmail.org/search/?q=list%3Anet.php.lists.internals more useful for that purpose. https://github.com/Danack/RfcCodex/blob/master/method_overloading.md provides a very high level summary on the topic. There's very little I'm sure about when it comes to the future of PHP, but one of the things I can state with some degree of conviction is that we will never introduce type-based method overloading. Regards, Nikita

Terje Slettebø

6 years ago
Hi Nikita. Thanks for your response and the links. I found the search engine you linked to working well. The reason I came to think of this issue was not as much to be able to do function overloading in general, but more from the fact that the discussion on operator overloading seemed to involve a lot of struggling trying to get it right when it comes to not preventing others from adding operator overloads for your classes, and so on, and free functions that can be overloaded provides in my opinion an elegant solution to this. The method using __call() given in the last article unfortunately doesn't work for free function overloading, since it only works for methods, and we're back to the question: Which class can or should provide an overload if you have two different types of operands? I also understand that PHP's dynamically typed system makes a difference compared to statically typed languages like C++ or Java. Given this reality, I guess the current userland operator overloading proposal may be the best we can hope for, and I for one would appreciate any kind of operator overloading to none at all. Regards, Terje