Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108336 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 37495 invoked from network); 31 Jan 2020 18:24:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 31 Jan 2020 18:24:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1F004180539 for ; Fri, 31 Jan 2020 08:35:49 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.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 ; Fri, 31 Jan 2020 08:35:48 -0800 (PST) Received: by mail-ot1-f53.google.com with SMTP id g64so7077346otb.13 for ; Fri, 31 Jan 2020 08:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eMov+nDJYjGJbrqgRXjRr2rmoMaCmgsnq4Exiy/4e/E=; b=vV4q4KvN3YjvY6xj8WGRx5mTMKiiMf9PHiT1olDWimUIIW2QN0lAi5a3yXL+EKWjWw y6aTbQLkvEdur+Dafyei9H/J/kyfkL1SnGf8TfgMRInElvZ0ATO6OdXWWp8tGVB5g6a7 54Sm8zOJO84G3h5xDpdm/jhdaab6o3EgZcKfIeqSH3xMYfBc7DjAZKSC/w2WlhhuyDt6 qe3yU7SdlnWMjjd8nErgVrFfQWFdINcXJoRijGjfqYYrBCMeCZIF4rcDZKDpwzvzZ+Io wafUzdPS0keTQJ9zKEc37bFbAA2gqyFjdEbMQ84QByiNhwUCdFgnFJuKrtIy0nVsGPCr KHyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eMov+nDJYjGJbrqgRXjRr2rmoMaCmgsnq4Exiy/4e/E=; b=q0+77r26HLhaORStkv5JpyQNrULkLBv9gUqFyLa+lOA3wYrLJXBzbj4tacRubiQM++ mKEmXm17jKazYMCQbSG1nFQy31Ostgq6pGgt8eApa6V/EKWNY5ACeJFy/JVOcb3LsuLY 4kdftYdMll5J9VIbaJqh1uV+fE+uFPogma3yf2VdZMj23Qv6g0eVc8rhqK0hajt9ZCdJ ZiN1r5u+HgecdvyBheBau5F+aYx88TLpqTx8IaNwyzEYOcXNlkjQ3czDUp102hxeAaJH 1/8SUm0KoJ5wui7UrgjL0C7iAri+oOy8+xDEp+GdFHfgoXP/UY/gCnM8hAkg9P5xT/2H 5/0Q== X-Gm-Message-State: APjAAAWsifQQnp5qlOCSMDMp2pGSpFEXqwSo6HCcfW5XgJ5eyUYiCuZH P9PB8IBrz04UzBVulUySpYD4rJ9DzIxrqOjJVq1vXjmA X-Google-Smtp-Source: APXvYqzm5zT0uc7zqrLuqncV3cDODSngqShyv5zZQpFEET71/ObfHV8UCtNw+u/PGyiokGMfqqZ5sbfKvzeJDJoTrmg= X-Received: by 2002:a9d:7083:: with SMTP id l3mr7995332otj.193.1580488547069; Fri, 31 Jan 2020 08:35:47 -0800 (PST) MIME-Version: 1.0 References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de> <001f01d5d7b3$68c18b10$3a44a130$@gmx.de> <7c915ed1-adcb-473d-a975-acfdbf7b1e33@www.fastmail.com> In-Reply-To: <7c915ed1-adcb-473d-a975-acfdbf7b1e33@www.fastmail.com> Date: Fri, 31 Jan 2020 17:35:33 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000006b7331059d722a82" Subject: Re: [PHP-DEV] Operator overloading for userspace objects From: benjamin.morel@gmail.com (Benjamin Morel) --0000000000006b7331059d722a82 Content-Type: text/plain; charset="UTF-8" I like this whole operator overloading thing. I would probably use it in brick/math and brick/money to replace verbose `->plus()`, `->multipliedBy()` etc. calls. > Can you only compare 2 of the same type? What about subclasses? Can that differ if a subclass overrides that method? What happens to commutativity then? Can you compare based on an interface? I think that this should behave exactly the same as if you replaced `$a + $b` with `$a->__add($b)` in your code. Nothing more, nothing less. The result will depend on whether you type-hinted your magic method or not. > These operators only make sense on value objects, not service objects, and value objects should be immutable. Indeed, we would need to make it clear that the operation must not modify the value of the current object, that should be effectively treated as immutable. Because it will probably be hard for the engine to enforce this, what about using the same convention I use in my libraries, i.e. `plus()` instead of `add()`, `dividedBy()` instead of `divide()`, etc.? This would translate to magic methods such as: __plus() __minus() __multipliedBy() __dividedBy() Benjamin --0000000000006b7331059d722a82--