Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102476 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52346 invoked from network); 27 Jun 2018 01:28:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jun 2018 01:28:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=rudolf.theunissen@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rudolf.theunissen@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender) X-PHP-List-Original-Sender: rudolf.theunissen@gmail.com X-Host-Fingerprint: 209.85.217.172 mail-ua0-f172.google.com Received: from [209.85.217.172] ([209.85.217.172:35194] helo=mail-ua0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/D7-01794-658E23B5 for ; Tue, 26 Jun 2018 21:28:54 -0400 Received: by mail-ua0-f172.google.com with SMTP id g6-v6so231534uam.2 for ; Tue, 26 Jun 2018 18:28:54 -0700 (PDT) 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=l9ZNhKyhT1JLL9pDHbgkJx6nxUnGL9ZPIWqXTV7RFRU=; b=VpvS24UO+YxSfWtjQHrc/YpaFFT+uT+Ixq2sItgTPwJ2oTObVQsnXhUXqsghnr5ycW 1cevhp2bbaGP5RMPQLgPYbl4V5QbaGfNmyoysdh8krk18osVXasUTHVJcVXczf1rbfCf RRi9r3Cn8cXfZbaNpTXSANlVzA1zbH/WwfHkzpdrXvDNYnwv/TXGfrCrroh0qjXRAkvS TgeIxkVfKxXRlcCNStID+RkxfTNPtNkEFhlbRaokNUZ2uwwCBcKzVc4A9xMpmwEl4Ltk LtLivaglH3MSG+pl6LpwGLWH3E+dqYLyvNT9yumrGc2Y7OYLNWDwYSDhzWxBrSCZi/Vx gFAw== 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=l9ZNhKyhT1JLL9pDHbgkJx6nxUnGL9ZPIWqXTV7RFRU=; b=bQY/ZWVmcTvfmJDaapz6DrmQ00lxsU68yb8c93GH03Pmi4jcwNclFdTtgw2b03ZVtD mO37OeSRO8sqvM1Do87YL88RSBVGNXQMUs4bGty+k3Qmihlk/VM9ng0gsDLAZTFbhEOd +XeVSCltkbQ5xO0n0/X9BFfENUexahTbXSxV8Mqb6prvE/MQPs1wwwl0aD7XHxMxH9ar hfL0u3pTVXNsYcsu257IJh+1mgLzSn06V3RuMzhju2UGo7qmX0kX+YzP4WvY0pH9oC68 PVn9FBEgRLA7unQCBXw/ihjTHDzGL3bP0NQtzA6L78gWU1ggI841mOmGed8vLTxWRVWR JZkg== X-Gm-Message-State: APt69E3AGhu+jc9cpXTPA8hQV4F35wPmbveR0LWdxdXxUFqHn98lQHad J4zf56D2n3NcrCIB8c0dqd6u4fAum/QkLr23bao= X-Google-Smtp-Source: AAOMgpcrl66MQb1QGzWW7OpRCi8g/qPUp51K6aLVdTwpSu8pE8S6CY1ZjpkorCFpPpuNCOYN5yxAgTn1wAXHLVVboms= X-Received: by 2002:ab0:76a:: with SMTP id h97-v6mr2516444uah.145.1530062931765; Tue, 26 Jun 2018 18:28:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 26 Jun 2018 21:28:40 -0400 Message-ID: To: netmo.php@gmail.com Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000883095056f95892c" Subject: Re: [PHP-DEV] [RFC] User-defined object comparison From: rudolf.theunissen@gmail.com (Rudolf Theunissen) --000000000000883095056f95892c Content-Type: text/plain; charset="UTF-8" > I would like to see this in an extension first, i think it's perfectly doable and people can test it before merging to core Actually not sure this can be done as an extension because it changes zend_operators and introduces a new handler to make it all work. > Would be nice if compareTo and equals were used only if left operand and right operand used the same comparator function. In other words, $a == $b must not work if $a->__equals and $b->__equals are two different functions So effectively it means we only call __equals if both sides are instances of the same class? > If $left operand and $right operand both have the magic methods, it will call $left->__magic($right), otherwise, if only the right one has the handler? What if the right one has compareTo and the left has only equal? you probably should add a table that explains which method is called depending in the availability of the two magic methods in the operands. Good idea. :) In brief, as it's implemented right now, the LHS takes precedence and the RHS will be called if it's the only one that implements the operation. I'll write some more tests for these cases and build that table for the RFC. > I'd introduce a debug mode that forces php to call both $left->__equals($right) and $right->__equals($left) so that symmetry is guaranteed by design. If we want to guarantee symmetry by design, we have to either compare both sides or only compare if instances of the same class, or document that comparison should be implemented such that a > b == b < a, etc. I'm not convinced that a double comparison outweighs the responsibility on the user to be sensible. On Tue, 26 Jun 2018 at 21:04, Wes wrote: > some ideas and concerns: > > - I would like to see this in an extension first, i think it's perfectly > doable and people can test it before merging to core > > - would be nice if compareTo and equals were used only if left operand and > right operand used the same comparator function. > In other words, $a == $b must not work if $a->__equals and $b->__equals > are two different functions > > - otherwise RFC should specify the precedence. if $left operand and $right > operand both have the magic methods, it will call $left->__magic($right), > otherwise, if only the right one has the handler? > what if the right one has compareTo and the left has only equal? you > probably should add a table that explains which method is called depending > in the availability of the two magic methods in the operands. > > - I'd introduce a debug mode that forces php to call both > $left->__equals($right) and $right->__equals($left) so that symmetry is > guaranteed by design. You could do that when "assertions" are active. > > gl > --000000000000883095056f95892c--