Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108788 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91458 invoked from network); 27 Feb 2020 22:24:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Feb 2020 22:24:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0816A1804D5 for ; Thu, 27 Feb 2020 12:42:56 -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=-2.6 required=5.0 tests=BAYES_00,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.15]) (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 ; Thu, 27 Feb 2020 12:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582836173; bh=DIL0uaUNe9ypLXKfB24vntTpkxkdl5m7FzIwuMNj3bE=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date; b=M2bQgq0345CW+vgtUrKLXcP7SRQ3jQE1AEmA7nu+ABUmdbouRopl2bRLpcNVXjgRB LRKp68vcnuGv6EDU+GfB19jQpTaQTEpg3ON4Y2oEG+KUCjzkcXocPzUUmLpmsB/x5R Uc4pIotEBzQYPSQiFpMW/xqPtHDzjyL+E4ud9zi8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from DESKTOPF2PTDOD ([141.35.40.65]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mqb1W-1jl8TV1Etk-00mex7; Thu, 27 Feb 2020 21:42:53 +0100 To: Cc: "'PHP internals'" Date: Thu, 27 Feb 2020 21:42:52 +0100 Message-ID: <005101d5edae$7b7c3e10$7274ba30$@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 Content-Language: de Thread-Index: AdXtqbbbZqxDM/JFSyS7llQDi6kHXQ== X-Provags-ID: V03:K1:tURpX96zDWbQ4LX2K2uGuLX7ZRdyv8/ttJeLllRBUxg2J00RvTN 9/gq3o/dgscO87RIuK/tNFDuoTrSRQaZwFe7VGiJaXm5VFXCga5HywjDrEDat4uyw+GPn+M EIHJjTRwMr7lWrwg3xTuia/B0ryrDUbrtjVLbEO5xffLybmKrWmeVaXJvxGP/3aH/jhytFY erKi85iD4p+Til5yChdJA== X-UI-Out-Filterresults: notjunk:1;V03:K0:8gpXLz0ByIg=:gpXKPyWA2t5D5nXQ0KDrEU oZlZ/5AlsEJs6NBX0CqxXEDZ8lM1RqOs7lSGe+axaZ9s/8lXei21vj8ebSFShCZ58ijlLWTgQ QqJQlV7d810LbvlryUIoYlj30meUr2gwsjNgEKE0TNqbdYNAp5s2lsNoOE9ddkLCKQ4zWRINh 92yoeFq5uVcw4iJfx4C/n4zXi8Or4UHJsvD8TFMKcVen/r/VKHUHL7GJrydici/EnGIUhV5CF 8/gl/TsRs3dcY2WLG3fDXWpBtE1+iR/iAhMQ1bzqRS1MebvqcogeZcbgBxq9P0wM9cT1ZJhAo Wdr2FEEyPZ7WwpNKLot14qYMHZ3/dIO8GBIw/PcLtWS2O/RzbLWkRrsbAjKNv8WyriCi2bAcp 31TvRlBZuAlSoAdCNXwmnS6GieerHF+Q+tAXapgzUfNv6p4aImfkJArRckdtc/uwMH4aBUkFv 2yP9tYcY+Pky1zLpSa+/h65nRVbSQUvzXWE94dla/wJNiLbN5VLJC4t7513d7DClhjg822rhq hdcTspS51FoMulZ07zGZiWV4dbq4wbR1pTWt+d5CkU7/ueOlbGhEraByVQkSABqvGiJVA4fSw 2700ltQfxfcllRqaJxhvP+cPGp8LMR+Pz4B4BA8ACt2TuFv2oLjzwUcH4ROCjw2JcYzZ0CJ9n nV0b5E70xtt998O0y6L+eYAqA1buspfhKwA/906b2y6DrHrVirAxW0Qk4dKHVglQ2iYfuaccj q/rZsWAQdpPs9O56s0CRjKFIHJJdPVzg9VoYFBPSn1K8+2DLSqkGj+x9XGmyqOAXg07QJj+ia w7jpNMGzGOtvr/xnwMRXDeyLE/76Uu+hLnKtFUDDXRxyTZy/gK8KcVnGUff0c8NdShp4+5krc KFR/4xNUTrUHVOy3basBxPD9oaSbj+XA82ypn32QGUfMzx9it3bePxlehE2fAdEN4tlRwsA18 cbUB2zK/eBPmQ9bFNK/t3LEyufhypaVHpsngYnKeJWp7yInt3vcsC/uNTdb4mby/kVj1EyINJ n8YRZ9ijcreWSOSCdIpIf14fBu03JiHUdNwMUNPyhwSjsMqP88GFL549mnhZr+XimWPFk4vtk 4Hlb6l8t/+FC7QOJFj+oa5L3S2z+CeOsW08S5S2pcMYa2dtVuVTlXCsAVq1jUd0XqpjtJ+PdL PbwAklLQgTMMVvhv3p0QionD7NPqZuedTw3vty4oWkyXFJaCb1JFOpvQcZptGbZYykLEXLacw YEZJtQ7WaqmqAFvAE Subject: Re: [RFC] Userspace operator overloading From: jan.h.boehmer@gmx.de On 15/02/2020 22:05, jan.h.boehmer@gmx.de wrote: > Hi internals, >=20 > 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 >=20 > 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. >=20 > What do you think about the RFC? >=20 > 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). >=20 > Regards, > Jan B=F6hmer I have changed the proposed names for the bitshift handlers to = '__lshift' and '__rshift' (instead of __sl and __sr) to make more clear what = operator is handled by the method (also the method names are now mostly = consistent with the Python equivalents). How many of you would prefer a interface solution for operator = overloading? I wonder if the RFC voting should include the option to choose between either the magic method approach (with the syntax proposed in the = current RFC version) or using interfaces. For an interface version I would suggest these interfaces: ArithmeticOperators (implements +, -, *, /), PowOperator (**), ModuloOperator (%), ConcatOperator (.) and BitwiseOperators (~, &, |, ^, = <<, >>). What would be appropriate names for the interface methods? If we just = name them after the operation (like add()), it will become difficult to = integrate these interfaces into existing code, as add() is already a used function name in many cases, but uses a different signature (non-static with one argument, whereas the interface needs a static one with two arguments). Regards, Jan