Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102716 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23522 invoked from network); 10 Jul 2018 14:45:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jul 2018 14:45:37 -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.174 as permitted sender) X-PHP-List-Original-Sender: rudolf.theunissen@gmail.com X-Host-Fingerprint: 209.85.217.174 mail-ua0-f174.google.com Received: from [209.85.217.174] ([209.85.217.174:42259] helo=mail-ua0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 16/47-15421-D86C44B5 for ; Tue, 10 Jul 2018 10:45:35 -0400 Received: by mail-ua0-f174.google.com with SMTP id x18-v6so14119791uaj.9 for ; Tue, 10 Jul 2018 07:45:33 -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; bh=aZdUlqxbpUpoLtVLBVv6hdcWVu3KA+z4uhIOTJEheJI=; b=R9eJYc+1W4DIHzaTfQZureNgpvDwiAdvHdVlEfFwgfA18sMwKWtkfGt4JNkqqaeJKN yU3QUtv8e+AXPGtK+v5iYiLI/GRUjQ4mNsttpmufSsIMjw18Rg7OdN4CyQRfVXM9UAZp vvq7IIsJqZPRVrM3offhpTBA9ug2sT2onfIEdUeqPX/NGfArWaS/N0jwZcsDc5OVbWML Hn3gRyvT9IL70tgr3rdMBRQJBlYAX05CADf1NORVowR24UrdlUjwY0qRYYoe3Umjq9Nh JZiiv9pbbTm3SwVuyD8pSV03jq2nhibrYQBb3FssEcAeYtV8vcKkL1xToL21syuxGvfd fs3w== 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; bh=aZdUlqxbpUpoLtVLBVv6hdcWVu3KA+z4uhIOTJEheJI=; b=k/Ns01iRBC6RxeQ91h17EvcC+PySR5MmzsFuoOANQjzGPywlXFjJsu4ODDcU6q7+W5 XlyjQGHXthRqHMX3xG1BPtohaUuMr7C5FixSC8arfd7ZUZwb5ahUEVL5m94Gwjg5sC7W Ym1Tzyg6FfivuJc33Avo+LjDdULSWsL5+jXHfS+CBqRvH54DMcyjrNNlkPMuOCWj1OX4 MxN7FWJCRd9ceFZj1KMhLrMut5uG+lCbm4XCCJhyuI9cMFcLu8knw/0zCFEUG/V26Trl wiE3poNW04nw7hIMeF5F41UpbrvrRGMKjE7ZPKsiui7/KRdbWze0JQCDF0XepGCyREmJ wZYA== X-Gm-Message-State: APt69E2lCG8zq+i7rDHhNB1UifigV5RCjMYWvJ3t96pKwZnLZ2XZ9EVJ sukOcGqY345p0W7KSsSUOsi1lffVrDAbKvT5XXkkEPHt X-Google-Smtp-Source: AAOMgpfE7d1tyrTjjYQ92P55/4A4Ke/b406i/anEvQZD3KdYnFpUQpqXGlIuQIGjStYC4LRBY/aFS8s2faOIT0PZU3w= X-Received: by 2002:ab0:7207:: with SMTP id u7-v6mr3053126uao.99.1531233930680; Tue, 10 Jul 2018 07:45:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 10 Jul 2018 10:45:19 -0400 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000081a3e80570a62e38" Subject: Re: [RFC] [VOTE] User-defined object comparison From: rudolf.theunissen@gmail.com (Rudolf Theunissen) --00000000000081a3e80570a62e38 Content-Type: text/plain; charset="UTF-8" Hi everyone, I had a chat with Levi yesterday about the operator overloading side of this RFC, and I'd like to try explain it as clearly as I can so that there is no confusion. Using <=> spaceship operator as an example, the operator is like a pointer that references the internal `compare_function`. When you use the operator, it calls that function, which in turn does comparison tests and eventually calls object handlers when comparing objects. This RFC is not suggesting that we change the pointer of the operator, but instead adjust the behaviour of `compare_function`, which the operator already points to. Implementing `__compareTo` does affect the behaviour of the operator, but it doesn't overload it. If in the future we wanted to add proper operator overloading, there would be a function like `__spaceship` that directly overloads the operator to change its pointer to something else. If this was to happen, `__compareTo` would still be used by `compare_function`, and used internally when sorting or searching. I realise that the behaviour of the operator can be changed with `__compareTo`, and is therefore no different to operator overloading, but that's not how we should look at this. The reason why <=> normalises to -1,0,1 isn't because the operator dictates that - it's `compare_function` that does that, which is what the operator points to by default. I hope that helps to clear things up a bit. :) On Mon, 9 Jul 2018 at 13:57, Rudolf Theunissen wrote: > Hi everyone, > > With no further discussion and no objection to start voting on this RFC, I > would like to move forward with the vote, which requires a 2/3 majority to > pass. > > *RFC*: https://wiki.php.net/rfc/object-comparison > > Discussions: > - https://externals.io/message/102337 > (June 21) > - https://externals.io/message/102473 (June 26) > > The vote will be open until 2018-07-16. > > Thank you, > Rudi > > --00000000000081a3e80570a62e38--