Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109268 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 17689 invoked from network); 24 Mar 2020 12:50:04 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 24 Mar 2020 12:50:04 -0000 To: internals@lists.php.net References: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de> Date: Tue, 24 Mar 2020 11:14:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <003701d6013c$9afe9750$d0fbc5f0$@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 87.81.129.66 Subject: Re: [VOTE] Userspace operator overloading From: marandall@php.net (Mark Randall) Message-ID: On 23/03/2020 17:58, jan.h.boehmer@gmx.de wrote: > I have opened voting on > https://wiki.php.net/rfc/userspace_operator_overloading, which allows users > to overload operators in their own classes. I am certainly not opposed to operator overloading, and would like to see it in the language. However, I'll be voting no because of a couple of implementation points: 1. I feel like the choice of NULL as the return type for not implemented is far from ideal, especially for 8.0 which provides for union type hints. 2. The error handling behaviour is too timid. If operator overloading is to become a first-class feature, error handling should reflect as such and any attempt to use objects without the appropriate handlers being installed really should result in an error being thrown just as it would be if an undefined method was called. Mark Randall