Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121387 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 45333 invoked from network); 18 Oct 2023 12:51:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Oct 2023 12:51:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A06FC1804B0 for ; Wed, 18 Oct 2023 05:51:17 -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=-0.7 required=5.0 tests=BAYES_05,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, T_SCC_BODY_TEXT_LINE 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-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 18 Oct 2023 05:51:14 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-d84f18e908aso7661800276.1 for ; Wed, 18 Oct 2023 05:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697633473; x=1698238273; darn=lists.php.net; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Gz+1DUErSluiI9TmY2mV6bB5tG0H/tH1QQEdw+E/q34=; b=I4RI89H69bVW6zmSBNzq7TcbWGrYfjWg7IOqUMJ1t4wNOl5QdZkCzAfEdbbtHyEGuR IaQ89LvOj4623zg5i8v3YrkAC5CXWuTee8WNDDTMSl2Focy2An21t32NQ6hjADjQCjZW e2l4Cxtos1olt8pagirMTk4qIhvl4zPuV1K6IOcnO6XoBsfBguFrku2J4qEq/MSzDJor 0Kc888F2BQoPDdtlZfbVGSbM4s2lMsFxkLNF4yxRuF0llyXBqDEbnyt76wi8lEVLLyWa KdVMorvVrA2NLlOjk+dNNx7mSZv9b+nQTp2lg9LhNVQuIRLm3MBCbLjGyejGTEvgnZdd VfoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697633473; x=1698238273; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Gz+1DUErSluiI9TmY2mV6bB5tG0H/tH1QQEdw+E/q34=; b=liOkWlcrVJbyvjyMTmdOMelzPRXHx+ydBUVsUXBxTgygYT92jaVzA9lFWRo3VTtEkZ x+7s1cnfgzAGqFBV3kgg3KPD+sx5gzvRf1H60zRBblSOg1MSNr6wX7SjSy3XlzrVt8Gv DP/yhVhkgFerBP31NHzsYmB3MnI37X2s14g1n9TW1tKvC61GRAJt4D94FNmtmwg0FXZy +J1zhI3ZF1eo/hWjCTQ458AFp+1kh62zpxLL+5xSiA0yebJEd1c3vYLmUDfQ38yHHwXA /5t+631Jlt+Am/teHKoZavluYk9K3vwXguqcti+WyqtEXGemJlV7Kb92CXEYFRxOR0JD 6IDw== X-Gm-Message-State: AOJu0YyUKowQ3sHtIU2yoejFDtTbRZ6LJ6BBOUUdCDxmqG+myPbKuDbw RSpr6WnJRwuXAMLt2zIXpOrlWQALDyt1c5wVy+VxufTAz9fTB997 X-Google-Smtp-Source: AGHT+IEuIQppdTUYczPhQIOmNyWM0ufAGAqTXBIietg/dudN5OdANpLTQuSKjMYdzeQh1+QAYuI9XuKANYEz+KQbYlk= X-Received: by 2002:a25:cbd0:0:b0:d9a:e337:b6a with SMTP id b199-20020a25cbd0000000b00d9ae3370b6amr5025428ybg.61.1697633473009; Wed, 18 Oct 2023 05:51:13 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 18 Oct 2023 15:50:56 +0300 Message-ID: To: php internals Content-Type: multipart/alternative; boundary="0000000000001e1fe00607fd18e7" Subject: Custom object equality From: someniatko@gmail.com (someniatko) --0000000000001e1fe00607fd18e7 Content-Type: text/plain; charset="UTF-8" Hi internals, There is often a need to compare whether two objects are equal. For example, a popular [brick/money](https://packagist.org/packages/brick/money) library has a `Money` class, which has an `equals()` method. However, this becomes tedious to implement such methods, when multiple nested objects are involved. For instance, Money has an amount and a currency. There were already suggestions on the mailing list to allow "overloading" existing `==` operator, and some suggestions went even as far as overloading `<`, `>=` etc operators. However, overloading existing operators may lead to a BC break between the PHP version which does support the functionality, and which doesn't. It won't result in a BC break in case it's an entirely new syntax, because a library or a project won't be able to write code which overloads `==` in say PHP 8.4, but with code which still works in PHP 8.3 - it will have to require PHP 8.4+. But if it is implemented as a magic method, then `==` will work differently for 8.3 and 8.4. I suggest thinking about introducing a new operator `~=`, which signifies that custom equality is requested. In such a case, `==` will work as it works now, and by default `~=` will work also like `==`, unless its behavior is overwritten via a magic method. If a magic method is not present in a class being compared, `~=` will compare two objects field by field, but using `~=` comparison rather than `==` comparison, recursively. For instance, a Money object may consist of Amount and Currency. If two Moneys are compared using `~=`, and Money does not implement a magic method, Amount also doesn't implement it, but Currency does, then Amounts are compared using `~=` which is equal to `==` comparison in this case, but Currencies are compared using their custom comparison logic. This approach allows combining - no BC break - `~=` is a new syntax which is unavailable in older PHP versions - explicitly showing an intent that objects are compared using a custom comparison, rather than standard PHP one - allow to skip writing boilerplate equals() methods which just forward equals() to the nested objects - standardize such comparisons on the language level Of course how exactly this operator looks may be changed, `~=` is just an example. WDYT? Regards, Illia / someniatko --0000000000001e1fe00607fd18e7--