Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
References: <CAHFNTwccchXDWnpy=rmxRJ+r6rJrr_gs3ojxim+rPQPsKPVvLA@mail.gmail.com>
 <CA+kxMuR7d5GmVxC0v+=+W_TAMLawunsKSCF73cawMbU5jKffQQ@mail.gmail.com>
In-Reply-To: <CA+kxMuR7d5GmVxC0v+=+W_TAMLawunsKSCF73cawMbU5jKffQQ@mail.gmail.com>
Date: Fri, 22 Jun 2018 07:31:28 -0400
Message-ID: <CAHFNTwcbY=nprJQw+U3bNyuO12PT4=hFgnsmdKpWrmabS3Kr5w@mail.gmail.com>
To: danack@basereality.com
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000001b40a3056f39606f"
Subject: Re: [PHP-DEV] Equality and relative ordering of objects
From: rtheunissen@php.net (Rudi Theunissen)

--0000000000001b40a3056f39606f
Content-Type: text/plain; charset="UTF-8"

> If __compareTo($other) gives 0 then there is no justification for
additional method.
> IMO you're duplicating functionality here.

I tried my best to explain that this is not the case. There are perfectly
logical cases where
two values are not equal, but have the same relative ordering. The best
example on my mind
is a decimal type with a value of 2.0000 and an integer 2. They're not
equal, but there's no
clear winner for ordering between them.

> When comparing objects should be obvoius to use `object` type hint not
`mixed`

This brings up an interesting talking point. Should an object's `__equals`
method only
accepts instances of the class (and subclasses)? So object == int would
always fail? Or
should we allow the method to accept any value and leave it to the user to
do an `instanceof`?

> That's true, but you want to compare objects not scalar types, right?

See above.

> I think if you want to push the RFC forward, a really quite strong
> case needs to be made for why having it be a language level feature is
> so much better (or even at all better) than having it be implemented
> in userland.
>
>
>
> For example, as it is available in other languages, giving an example
> of some code that is much better than the equivalent would be in PHP
> could be a good way of showing it is desirable.


1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`, `!=`
with a userland implementation.
2. Therefore, you won't be able to affect the internals of array functions
like `in_array`, `sort` etc.
3. Having it as a language level feature dictates a standard, which is
often hard to establish as a third party.
4. There are some minor but worth mentioning performance advantages in
having it be part of the language.

Not sure if that is a strong enough case, happy to elaborate some more and
provide some code.

On Thu, 21 Jun 2018 at 10:59, Dan Ackroyd <danack@basereality.com> wrote:

> On 21 June 2018 at 10:27, Rudi Theunissen <rtheunissen@php.net> wrote:
> > The Comparable RFC (http://wiki.php.net/rfc/comparable) was written in
> 2010
> > but was not conclusive. I would like to take
> > on some shared responsibility to push this forward and re-open the
> > discussion.
> >
> > Why is this useful, and why should it be added to PHP?
>
>
> I think if you want to push the RFC forward, a really quite strong
> case needs to be made for why having it be a language level feature is
> so much better (or even at all better) than having it be implemented
> in userland.
>
> For example, as it is available in other languages, giving an example
> of some code that is much better than the equivalent would be in PHP
> could be a good way of showing it is desirable.
>
> cheers
> Dan
>

--0000000000001b40a3056f39606f--