Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116709 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 82249 invoked from network); 21 Dec 2021 21:16:55 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Dec 2021 21:16:55 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 66B2C1804B4 for ; Tue, 21 Dec 2021 14:20:43 -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_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-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (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 ; Tue, 21 Dec 2021 14:20:43 -0800 (PST) Received: by mail-lj1-f176.google.com with SMTP id m12so596175ljj.6 for ; Tue, 21 Dec 2021 14:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/2ioIe9KxYhoo/7gLOMoAWJ9oiF55PzWFwQXrrjlaLk=; b=h9s8F8lQKLTTz90zvyIakKIJZrPj49YBFFZVLxy+SyBJtC9gZtETWKkO+3m72VAJmj 7Qn8HjXrmPdvU+q+7AOAjUK7kQzb/Oo3OJLUR1MEGuPPm+SwVe5Z54xmQ7WJx8Z2tIgo oEI9CQR6tdXvyTTd83gIPgWJWMwpvkI3svkqKdthdYta1OxV916+xjFRRnuozFtK4wXH Hv2IcLIqVlkEgGfN/0hD36tMtNsHphd/rf1OGvxEVo7o0fyCSwJB3zDIxplLfQRiS+6q iW4fS0/M7C1yvpgSphIsHRhVcjwCfdQOOr4XKaPINWOQroC4U93JMYNzYdw7LBfLtylC mypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/2ioIe9KxYhoo/7gLOMoAWJ9oiF55PzWFwQXrrjlaLk=; b=HJIpQtj0qqe645Ms957v9ROjKM/4cvwFkakAYh/jljI5rv4QJG2WY7PwnkOcdzUfDF MPzPJPSvoDARk/xLJ2XaPuMofmKWUZts+aoE2zd+jsRR9awaYg8eYclzTGBttHYIWxh3 J/MaY7zwBIDwHTAhw1fCUrgT8KqgqFxFMWMEccCbRY1UOsnzenlTNQkyyX+TbjZwoBO6 APxradJJMJXdNoPUYXr0lzdEK7EEn4EZG0ACt0WlQyTu6Gg2YaWaqVPTK1S3HLF0xs+V tPV9Qd7sUvIDmhkvrm14ngdT9xSNLP0llZzwHD6qHn41PL3fRDvESWmmwbV+mbbwEr0t xGPA== X-Gm-Message-State: AOAM532T6wcYsub2OwFL4Q8+rs+1CyUTc+xNRlEKazUqYolVF8LQWkab iO98QdrJ/dAuhRkUhXajm9iVa9z83rO993ONb64= X-Google-Smtp-Source: ABdhPJw4U/e0zl6QSwd2ZOd7aVKIuZ9n+tXRFlX1sB96xuodImD36ChZhNmKUJrsiWiHKWmiHWaKqn+6YaW4LKwqZLk= X-Received: by 2002:a05:651c:1211:: with SMTP id i17mr320931lja.340.1640125241325; Tue, 21 Dec 2021 14:20:41 -0800 (PST) MIME-Version: 1.0 References: <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com> <4b58c011-ed87-ba87-201d-0cf8e4116c6f@processus.org> <67431363-cd1e-9575-7d51-0f4d265d05b9@gmail.com> In-Reply-To: Date: Tue, 21 Dec 2021 14:20:29 -0800 Message-ID: To: Andreas Hennings Cc: Dan Ackroyd , Stanislav Malyshev , PHP internals Content-Type: multipart/alternative; boundary="000000000000657b0f05d3af6a7b" Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6) From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000657b0f05d3af6a7b Content-Type: text/plain; charset="UTF-8" On Tue, Dec 21, 2021 at 5:47 AM Andreas Hennings wrote: > I see the "Implied Operators" section. > I assume this means that a new instance will be created, and stored on > the same variable, _if_ the original operator is written in an > immutable way (which it should be)? > > E.g. > > $money = new Money(5); > $orig = $money; > $m2 = $money + new Money(2); > assert($money === $orig); // Checking object identity. > assert($m2 !== $orig); > $money += new Money(1); // Equivalent to $money = $money + new Money(1); > assert($money !== $orig); > assert($orig->amount() === 5); > > I think we need a strong recommendation to implement operators as > immutable. > Yes. The documentation for operator overloads should be much larger than this RFC, and if this passes my focus for the rest of 8.2 will be on two things: - Working on a few smaller follow up RFCs (sorting/ordering enum, polymorphic handler resolution) - Working to help on the documentation of this feature All of the examples in the documentation should be for immutable implementations, and there should be an explicit recommendation for immutable implementations as well. With operators, mutable versions are created with the operators under the "Implied" section instead of by creating an immutable implementation of the operator itself. Jordan --000000000000657b0f05d3af6a7b--