Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115656 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 83155 invoked from network); 7 Aug 2021 18:37:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Aug 2021 18:37:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 063A31804C8 for ; Sat, 7 Aug 2021 12:07:05 -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=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 7 Aug 2021 12:07:04 -0700 (PDT) Received: by mail-wr1-f53.google.com with SMTP id h14so15603929wrx.10 for ; Sat, 07 Aug 2021 12:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=S1wqqvfRj+sq7zDsipUPmKBFa3Zh+kSQOFLFeK3VFN8=; b=bQdulPVrjQl5jFa+B9RZp6+9GikDChT0xHkp7p9W/s8NEheAvLGx2J/jGucC26I0Tn 4nW4z4tnnQyIN1eXy+A50dWKDKkp9dBBaX31jz53es9bxMkcUgeCyrcO0hGIbE165n9J ZSZn6/OHhigw0IdouoChu6o/EyvOljqdMXmeiaPBLzWh4FU6qcyjs4GSO4gYnsaZM+c/ ZN+EBgziC79J1XLKYjj3i+IYCV0T+IiXEW6JQdjff7khsWdM3nOIlOKxHO2EVjAdtMji aU4JPUJ54zTgTwaxx6mJNIcMM2EDZtWO84BCtzreBRkaMLCHdwJ3fCYn7AzOuGh7iUB8 XuKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=S1wqqvfRj+sq7zDsipUPmKBFa3Zh+kSQOFLFeK3VFN8=; b=b3cPkpRgSig0O8V32nsVmyR9/DJ9fOPdna7Y4fcwPgvbKJQCCwmJ+wAZ7HcMec28/C 5rPQae58dYdOqDIHHBO4ni6JD/cXTL2dHy9V9Hb1dXzHurs5cK0fBZtcXpOfsEUTMPtP PxMDVGNkaanOeXCLsPrb6pCSAuq4UevhjR41IM+cLC9pYBUtkDxHxgJ6db02B7p2/9Ry gfPbbB2SFbwsTD0e5r1nu08kl8vSlu7RCrgGFKXpD/RZqt1Jb0oqGCXsxJ2tBcdqvhei D9RioILTGbkWDz7dlsfCbJE4I/+9jJXdaundWAzMWMKD6zUN/rSzm0Ob9GXITyc+NBr9 mLtg== X-Gm-Message-State: AOAM530ibVs7BT58RCa5e9mF3OA4LPgzP071iL8vMkW1QYDkt+9AgXJf 3dlljLjG/mtBGbp0QWqE7Z9TyByBdIM= X-Google-Smtp-Source: ABdhPJxy/o2ikMy0QsrdPb/htyNkCPdzqdx3tcsXUkpH962PRWq5iOUFINfDyq1mdKBi5EYoV3fdcw== X-Received: by 2002:a5d:6708:: with SMTP id o8mr16932583wru.304.1628363223445; Sat, 07 Aug 2021 12:07:03 -0700 (PDT) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id d67sm18415362wmd.9.2021.08.07.12.07.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Aug 2021 12:07:02 -0700 (PDT) To: internals@lists.php.net References: Message-ID: Date: Sat, 7 Aug 2021 20:07:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads From: rowan.collins@gmail.com (Rowan Tommins) On 06/08/2021 17:34, Jordan LeDoux wrote: > 1. The only supported operators in the RFC will be the mathematical > operators: (+, -, /, *, **, %) > 2. The RFC would also provide an interface, (something like > MathObjectInterface), that has all the magic methods in it. > 3. The do_operation would be changed to check for the interface being > implemented instead of the specific method. Hi Jordan, In a previous thread [1], I wrote about two fundamental design approaches to operator overloading: a) Treating operators as arbitrary symbols, which can be assigned any operation which makes sense in a particular domain. b) Treating operators as having a fixed meaning, and allowing custom types to implement them with that meaning. Both approaches have their pros and cons, but my general impression is that approach (b) has more support on this list. For approach (b), I think your proposal to group operations into interfaces is a good one - it doesn't prevent someone using the operators to mean something completely different, but it expresses a clear opinion. I think using "+" for a union of two collections is really an example of approach (a) - it doesn't really mean "add", and it's no less arbitrary than using "<<" to add an item to a collection (as is conventional in Ruby, for instance).  If we want to go down that route, and allow individual operators to be overloaded, I think we should look for a syntax that lets you pick the symbol, rather than giving them names which only make sense in some contexts. [1] https://news-web.php.net/php.internals/108347 -- Rowan Tommins [IMSoP]