Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108608 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 5516 invoked from network); 15 Feb 2020 23:50:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Feb 2020 23:50:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id F0D4718050A for ; Sat, 15 Feb 2020 14:05:54 -0800 (PST) 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.7 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8560 212.227.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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, 15 Feb 2020 14:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581804352; bh=jt3az+6oN1DDD7p+Wn2hbK8rd9nB3RDNQQxWzUDb1Ig=; h=X-UI-Sender-Class:From:To:Subject:Date; b=GtQHA1LLToPwBI9TRNfWCbjCKuirbl6FnGHoHqoZ6fJXSjGUtRRmbv6fmPZpwCmn8 UTg6jEZVw5MQxZQEvNTAWB44ZqAvP5WwfY+97Pl9MfzSMJ1re5MMwSXm0hSTZ8MiG9 36MZVUac7lccp4r+FSH5vMJzuRtpIfyEiU0+uDso= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from DESKTOPF2PTDOD ([141.35.40.65]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M9o1v-1j8srt1wg9-005uUl for ; Sat, 15 Feb 2020 23:05:52 +0100 To: "'PHP internals'" Date: Sat, 15 Feb 2020 23:05:52 +0100 Message-ID: <003801d5e44c$169700e0$43c502a0$@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXkRm51C5pqRjwaQM2KDQD8Wi0nXg== Content-Language: de X-Provags-ID: V03:K1:1qqE4iTYZftesqJEvF+2w4k1R2K629C9hxjfVaSwWQ0L0b/UTtS 4EsqLBzD6pibopYfBwpvzIkTI1V8UsoilPRKWUTH7BVZaXyPMWl2JKMZty9pxPRhLYwGTxc dTiMjHNy7KRnAkEvptm7Ty3V8oWnZVSRCN0Rqw+wbYhsQaZV0HIiOSJkF8RHefUxFDwaz6O 9S0dz1ECRb1ormT9FVEGA== X-UI-Out-Filterresults: notjunk:1;V03:K0:jm4tAcCeBps=:tOx+nnn/7BzupwQhuS5ZXV +LVOizd5c5xVYvOYwnXb/0epP6jlFq87jVwGrDLcUOW/MiTQOFWBodnfGUV8G9IkAXJOqhLeE TLraertVixxvnl7V2lKIAG4fpHh9QB31pFT93SarI+JACWY9VGZwnNAcadTV5qzxaRVVe9J7l w7krWKItDFY4WzGydb2TiSZ3HDb2zZW1e5yaKS09AqzNmAWEPznnsRwEH42bGxGvVtKM+obc8 Bi3OmfaZkCKLr1RdK1mUQTwMFPByaMaGeUseJ1VggU86VDNAPR4Vv/mjeC4AXfcv1HRv6FN4j hqQ2tNCN7EMrMZtAeZVAmQ07eCxoqow+utl6geFkgIzh+LH1TGZPKrc1v16VWrm65sTvKrjKN fxow/hLw3Yecgcr1vh8ma3Cwg/C0DPGl+D4PhM3ygygkNwrhCT0gj9rBk/8p/kS5NkKxb1gpI WzuuNXlkiZ+N7kt4qV2f7s0R3yT0BAU2X3ZqAz67zf7fXEx3JiS/U5xC1S3YnZVpVggis2xDK 2hBWVs7LHDBU1fQ+kFumda5FqsxTixTap0zzzFMvsypUY3qEJFnNdR2B3jg5BjJ36Wfu+78mD 3FRB5acBXr4Oo2UKv67oW3aM1OpuWGCmEU0L7Vefl/zftvoFDc8X4t7lTf9XNf+QlO/bZwJXS krfHQVr5E1sAhmWc9/00cmuOYS9fQdiCws0tUEuBmB5Yi3RYPQEBt+DMz6pQHZ86Wiq5/lPHZ f7yOxXEjvu1JiCGww+kLC1KcACQUiOeRjq1hxaKBjyUhQM3WbkbsWXkrPEjzDpTMgW6lTwWEa Nw6/BGjmYknJ8XUQnZ2BAOVF41lmT9sCn40drznNmbZ2ULkP9Z2jKrWbtJfe108xjz4D/ChYk fEjp9cU9tzzUQybGmA5kpypCVyvFvgASuRLnO0igOhixzDDaGbjQR5wpx7sbfGRx++gGEb0zy I4wtEUI7wsjuu/GzxW9XZ218iOc+cIIgWhbuFfkrPJVfsm1QgvW5iT6AtVOg0t16ovUR3Y42l lUCxn3UtXVo7obFJXO1vPa8cIUvgakTIaG/Splc2b3zGn8VTmsHb1gyLNE/SoSu99OOq62/WF GhSBCSHkHhVcIK47N/xJ5wv7nDzTkNeNyZrkCTAJJc5EywuL7UgNoaBVfAanjg4DImn1jeJmI UepfBZe/s9I+ePsFjjTb8AIcgsVIH2p5C69oy/2mF3eUh/9LKy05BI2OR/5ngMZVaCbgq9I2R E9Djel+YJSIN09xrM Subject: [RFC] Userspace operator overloading From: jan.h.boehmer@gmx.de Hi internals, based on the discussions here (https://externals.io/message/108300) and = here (https://github.com/php/php-src/pull/5156), I have created a proper RFC = for userspace operator overloading: https://wiki.php.net/rfc/userspace_operator_overloading The main differences to my original concept, is the removed __compare() method (comparison overloading is a complex topic and should be handled = in a different RFC) and the possibility to signal that the operator handler = does not support the given types (by typehints or returning a special value). This way, only one of both objects has to know about the other type. = This should expand the use case of operator overloading compared to my old concept. What do you think about the RFC? Some discussion points, I can think of, would be the naming of the = methods (maybe naming them after the operator symbol and not the arithmetical operation they represent, e.g. __plus instead of __add) or putting the methods inside of interfaces like done for ArrayAccess (But I don=92t = see any advantage in doing so, as it is very difficult grouping different = operators in a single interface usefully. Also, operators can accept and return different types, so there is no real common interface between classes = you could rely on). Furthermore, maybe the idea of allowing operator overloading in general should be discussed as it is sometimes considered an anti-pattern (e.g. = the usage of '<<' for outputting a string in C++). On the other hand there = are many languages and libraries where operator overloading is used = successfully (e.g. numpy in Python). Regards, Jan B=F6hmer