Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102396 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15492 invoked from network); 24 Jun 2018 17:28:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jun 2018 17:28:54 -0000 Authentication-Results: pb1.pair.com smtp.mail=rudolf.theunissen@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rtheunissen@php.net; sender-id=unknown Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.195 as permitted sender) X-PHP-List-Original-Sender: rudolf.theunissen@gmail.com X-Host-Fingerprint: 209.85.217.195 mail-ua0-f195.google.com Received: from [209.85.217.195] ([209.85.217.195:40003] helo=mail-ua0-f195.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/9B-13077-4D4DF2B5 for ; Sun, 24 Jun 2018 13:28:53 -0400 Received: by mail-ua0-f195.google.com with SMTP id j17-v6so781948uap.7 for ; Sun, 24 Jun 2018 10:28:52 -0700 (PDT) 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=xiJuAWHn/753OfIxWaovmpiNW+9cVX++Iho5OF086To=; b=I9gXDUQI8GdyJD4wo9cH4Snm0wqg++CkgYq+hBE8ePuWzOlxI7bc5awaBnTxonqhBz zs66CquaJW3TLUqMDLHBdbM5VM/E5/yEsFNK1lMyXv1UUYD8LFMTFBJDFcWyBXKkwq6P 2z1Zfp7fK5tSiALDE62A0cc1JmuWV4vT6eacpPtIDYaq35f0PV4UIc202s7fZR6Xd4SZ U8HUAly5OzoIlgkQB72On+PgLilnhlxS7nVRjgDF6l+oNHdEzDxRAjsFGO/Hp7wZhZcG tGYkUQT6whMgpFWPLEoxB8YnK/fUZqdJTt2anUYUFHwgQOumg5PjZofGdfIXtJtL1GX9 5iFw== X-Gm-Message-State: APt69E1h/ePRVDaTsxnC7p/9sxJa/YEbsY/xwBV9iul+EkioLglWFGnQ dVue1nnEiDfZIaLDgtWDsD2EA240 X-Google-Smtp-Source: ADUXVKKqsByVrM86QMtmzofl1gGWt3dFDESA7xhmcK5ijNiY1KPLkx5NfLnDP2A0ULqh6192AmWCtQ== X-Received: by 2002:ab0:20c4:: with SMTP id z4-v6mr4716167ual.195.1529861330023; Sun, 24 Jun 2018 10:28:50 -0700 (PDT) Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com. [209.85.213.53]) by smtp.gmail.com with ESMTPSA id r128-v6sm738079vkb.18.2018.06.24.10.28.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jun 2018 10:28:49 -0700 (PDT) Received: by mail-vk0-f53.google.com with SMTP id o71-v6so6567895vke.7 for ; Sun, 24 Jun 2018 10:28:49 -0700 (PDT) X-Received: by 2002:a1f:e346:: with SMTP id a67-v6mr3493230vkh.172.1529861328846; Sun, 24 Jun 2018 10:28:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 24 Jun 2018 13:28:37 -0400 X-Gmail-Original-Message-ID: Message-ID: To: levim@php.net Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000000fc53e056f66993f" Subject: Re: [PHP-DEV] Equality and relative ordering of objects From: rtheunissen@php.net (Rudi Theunissen) --0000000000000fc53e056f66993f Content-Type: text/plain; charset="UTF-8" The idea behind the nullable return is to allow for partial support, where you might want to check for equality but ignore ordering. You can't return nothing or NULL if we normalise to -1,0,1 because NULL would be 0 and therefore indicate that the values are equal. We could require that the user always returns an integer, and suggest -1 to be returned when there's no clear definition for ordering. The null return was to avoid returning that -1 when ordering isn't defined. ``` class Equatable { public function __compareTo($other) { if ($other instanceof self && $this->prop === $other->prop) { return 0; } // No logical ordering exists, so we're not concerned? } } ``` As it stands, we have a few options here: 1. Allow anything to be returned and normalise to -1, 0 and 1. 2. Require an integer, error when anything else is returned, suggest -1 as a comparison-not-defined convention. 3. Use NULL (or void return) as an indication that the comparison couldn't be made, fall through to compare_objects. 4. Use NULL (or void return) as an indication that the comparison couldn't be made, internal error. My vote at the moment would go to #3 or #4 because it's the most flexible and the NULL is an edge-case. On Sun, 24 Jun 2018 at 11:30, Levi Morrison wrote: > On Sun, Jun 24, 2018 at 8:11 AM Rudi Theunissen > wrote: > > > > Here is a WIP implementation of `__compareTo`, with some decent tests. > > > > > https://github.com/php/php-src/compare/master...rtheunissen:rt-compare-to-magic-method?diff=unified > > Help me understand the nullable return. If you are defining this > operator then by definition you don't want the standard behavior, so > why is returning null helpful? Seems like implementors ought to throw. > --0000000000000fc53e056f66993f--