Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102401
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
References: <CAHFNTwccchXDWnpy=rmxRJ+r6rJrr_gs3ojxim+rPQPsKPVvLA@mail.gmail.com>
 <CA+kxMuR7d5GmVxC0v+=+W_TAMLawunsKSCF73cawMbU5jKffQQ@mail.gmail.com>
 <CAHFNTwcbY=nprJQw+U3bNyuO12PT4=hFgnsmdKpWrmabS3Kr5w@mail.gmail.com>
 <CA+kxMuT09fhHOc1NpZhfsFkmq2vtm1apK3Ktj4ysN5etubRPCQ@mail.gmail.com>
 <CAHFNTwffwu=GTi3u=gS5nNf0AgjywPPE-2YJNpXZpKte__Wh6w@mail.gmail.com>
 <CAHFNTweymOruLojRwcfhsAZTDrPwvQA86cK3cBziPd5diba3TQ@mail.gmail.com>
 <CAHFNTwdq1eWVhFxdkdsRi-fdwqVML97pWxdssjbneBc2Op0Q6g@mail.gmail.com>
 <CAHFNTwfac=F+55jCFSfqhsZ5odypjmdNem7ixXPsrZfny97Jng@mail.gmail.com>
 <CAFMT4NryR1cH=dsMhX6VLn2pRbBH9TMLjgDj-jdQ_XEbRhkT7g@mail.gmail.com>
 <CAHFNTwc5i8G=LwZ13vr7fRM4_3LTwLoug=5No9_jo5hUuXZGPw@mail.gmail.com> <CAFMT4Nqk-7LUyESP7HbTov5myDChtSd2Z17Px-VNBZef2gQ32A@mail.gmail.com>
In-Reply-To: <CAFMT4Nqk-7LUyESP7HbTov5myDChtSd2Z17Px-VNBZef2gQ32A@mail.gmail.com>
Date: Sun, 24 Jun 2018 16:31:20 -0400
Message-ID: <CAHFNTweaxwG81MOPiyC6QJJN_oF-mbpgOcJzgtz6Sj54rdR1cQ@mail.gmail.com>
To: levim@php.net
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000083e186056f692655"
Subject: Re: [PHP-DEV] Equality and relative ordering of objects
From: rtheunissen@php.net (Rudi Theunissen)

--00000000000083e186056f692655
Content-Type: text/plain; charset="UTF-8"

>
> Other languages (most? all?) separate equality and ordering for this
> reason.


Java doesn't really separate them. Their `==` always checks object
reference so is like PHP's ===.
But they do have the .equals() method on all objects (our ==) and the
collections use that for equality.

In these schemes I am not understanding how to specify that something
> is not equal, not ordered, and should not fall back to something else.
> Consider things like UUIDs and other identifiers where equality is
> desired and ordering does not make sense.


For something to be not equal, you return anything but 0. If something is
not ordered, you return -1 (LHS wins).
If you don't want something to fall back to any default behaviour, just
return an integer and not NULL.

The realistic case, in my opinion, is that there will always be *some*
property to order by, whether it's the object's
numeric value, a string that can be alphabetical, or a time based element.
We can argue that if the object doesn't
have a defined, logical ordering, then it also wouldn't make sense to order
a collection of them in the first place.

So with that in mind, maybe it's okay to take "NULL falls back to default
behaviour" idea out, and do a normalisation
on whatever the user returns. If it's NULL, then that'll be 0, and the
value will be equal. The only thing I don't like about
that is that the user didn't specify "equal" with a 0, they returned the
absence of a direction, and we should therefore
either throw an exception internally, or fall back to the current
comparison behaviour (comparing properties).

The NULL return is a special case for me. Anything else is *some* value
that can be normalised ($v ? ($v < 0 ? -1 : 1) : 0).

Therefore, I believe it comes down to a simply question: how do we handle
the case where __compareTo returns NULL?

--00000000000083e186056f692655--