Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109380 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 27266 invoked from network); 28 Mar 2020 12:44:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Mar 2020 12:44:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 212831804E4 for ; Sat, 28 Mar 2020 04:10:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29695 109.247.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from asav22.altibox.net (asav22.altibox.net [109.247.116.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 28 Mar 2020 04:10:05 -0700 (PDT) Received: from [192.168.43.212] (telia-b00b12-41.connect.netcom.no [176.11.18.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: terje.slettebo@sandefjordbredband.net) by asav22.altibox.net (Postfix) with ESMTPSA id 0B2DE200E0 for ; Sat, 28 Mar 2020 12:10:02 +0100 (CET) To: internals@lists.php.net Date: Sat, 28 Mar 2020 11:10:03 +0000 Message-ID: Reply-To: =?utf-8?q?Terje=20Sletteb=c3=b8?= User-Agent: eM_Client/7.1.33101.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBB40B9C61-D372-4519-AF58-F0D52C199EF4" X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=ZvHD1ezG c=1 sm=1 tr=0 a=rKset9nUwlxuoxh/NJjZ0Q==:117 a=rKset9nUwlxuoxh/NJjZ0Q==:17 a=M51BFTxLslgA:10 a=67BIL_jfAAAA:8 a=1IYs5flBWiBgHq4ZttIA:9 a=QEXdDO2ut3YA:10 a=CnBqMGZJvREA:10 a=k8TENevXof0DvGaL2UEA:9 a=y0dRn8PTec52RRDh:21 a=_W_S_7VecoQA:10 Subject: Function and operator overloading From: terje.slettebo@sandefjordbredband.net (=?utf-8?q?Terje=20Sletteb=c3=b8?=) --------=_MBB40B9C61-D372-4519-AF58-F0D52C199EF4 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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:=20 https://www.php.net/results.php? q=3Dfunction+overloading&l=3Den&p=3Dall 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 =3D new Money(100); $m2 =3D new Money(200); $p =3D new Percentage(10); $result =3D $m1 + $m2; // Money(300) $result =3D $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 --------=_MBB40B9C61-D372-4519-AF58-F0D52C199EF4--