Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109387 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66436 invoked from network); 28 Mar 2020 15:04:30 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 28 Mar 2020 15:04:30 -0000 To: internals@lists.php.net References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de> <7a83f950a31d94d5ff2307ac8219db3b7b6482b6.camel@schlueters.de> <12ad7c71-8958-7742-12c4-e83e359c8186@gmx.de> Date: Sat, 28 Mar 2020 14:29:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: <12ad7c71-8958-7742-12c4-e83e359c8186@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 46.59.72.204 Subject: Re: [PHP-DEV] [VOTE] Userspace operator overloading From: ajf@ajf.me (Andrea Faulds) Message-ID: Hi, Christoph M. Becker wrote: > On 28.03.2020 at 10:22, Arnold Daniels wrote: > >> This issues become even more apparent when sequencing operations like `$a + >> $b + $c - $d`. Trying left, then trying right, will make it very difficult >> to determine the outcome of such a statement. >> >> The arguments against type hinting for operator methods, assume the "try >> left/right" method. Instead, type hinting should be applied to determine >> which method should be used. If both or neither methods are applicable, an >> error must be thrown. > > This "try left/right" approach is how operator overloading works for > internal classes[1], and apparently, it works quite well, as long as it > is not overused. I think “as long as it is not overused” are the key words there. We have a very limited number of internal classes with operator overloading right now, and the authors know about what other such classes exist and therefore can design with them in mind. But once any userland PHP class can use operator overloading, you could start seeing uses of operators where the left- and right-hand side are classes from unrelated libraries whose authors were not aware of eachother, and that could create strange problems when one or the other library is updated with operator overload handling. Consider Arnold's example: $a + $b + $c - $d We are not constraining operator overloading to just be for number-like objects, it can in principle be used for absolutely anything. $a here might have an overload that works for any right-hand-side object, but then once $b adds its own similar overload in a new version, the code no longer does the same thing when it's flipped around ($b + $a), violating the normal expectation that `+` is commutative, and that's before considering what $c and $d might do! Thanks, Andrea