Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.180 as permitted sender)
To: internals@lists.php.net
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>
 <CAHFNTweaxwG81MOPiyC6QJJN_oF-mbpgOcJzgtz6Sj54rdR1cQ@mail.gmail.com>
Message-ID: <914c2c94-6467-fadb-9d44-fb8f5c60e12c@gmail.com>
Date: Sun, 24 Jun 2018 21:56:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAHFNTweaxwG81MOPiyC6QJJN_oF-mbpgOcJzgtz6Sj54rdR1cQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Equality and relative ordering of objects
From: rowan.collins@gmail.com (Rowan Collins)

On 24/06/2018 21:31, Rudi Theunissen wrote:
> 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).


Since this is a method, and not just a callback passed somewhere, could 
we simply mandate that the signature has an "int" return type?

That way, if the class is written with strict_types=1, it will throw a 
TypeError for null, and the user will have a big hint that that's going 
to happen when they write ": int".

Regards,

-- 
Rowan Collins
[IMSoP]