Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102519
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
To: internals@lists.php.net
Date: Thu, 28 Jun 2018 16:12:41 -0500
Message-ID: <1662423.y1zp7GJX4B@vulcan>
In-Reply-To: <CAHFNTwevL1aW498JpOhyeVPFq9Jhynnmmk5-Rpxebxo9zD8oMQ@mail.gmail.com>
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com> <CAHFNTwcQf+7B2Jb7ZjBFx625PN4ouRmf5+DjMWOWGB0KKzyRRg@mail.gmail.com> <CAHFNTwevL1aW498JpOhyeVPFq9Jhynnmmk5-Rpxebxo9zD8oMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1625463.McxDEkl6s1"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: larry@garfieldtech.com (Larry Garfield)

--nextPart1625463.McxDEkl6s1
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Wednesday, June 27, 2018 5:58:29 PM CDT Rudolf Theunissen wrote:
> Hi everyone,
> 
> I've made some changes to the RFC and the implementation today to explain
> some of the edge cases and combined behaviour better.
> 
> There are some issues towards the bottom of the RFC that I would really
> like some opinions on. They all have decisions made but are not concrete,
> so I'd like to know if anyone has strong opinions on them before they are
> considered a final part of the RFC. I'm happy with the current state but
> I'm very open to changing those decisions if there's a good enough reason
> to.
> 
> See https://wiki.php.net/rfc/object-comparison#open_issues
> 
> Thank you

Overall, I like.

Regarding what is legal to compare to, it seems useful to leverage the 
optional type hint.  So given:

class Foo {
    public function __compareTo(Foo $other) {}
}

class Bar extends Foo {
  public function __compareTo(Bar $other) {}
}

In this case, the order of checking to see what method to call will also check 
for type compatibility.  That is, $f < $b checks Foo::__compareTo(), finds it 
doesn't match, and so calls Bar::__compareTo() instead, which does.

"However, because magic methods aren't inherited" - Wait, they're not?  Are 
you certain of that?  Because 3v4l.org says they are:

https://3v4l.org/P6Hlq

I don't understand Future Scope point 1.  It... means we're already covering 
those operators.  Why is there future scope needed?

I otherwise agree with the current Open Issues directions.

--Larry Garfield
--nextPart1625463.McxDEkl6s1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAls1T0kACgkQ4MMKwDFx
YXehVAgAvDJFJd+4K59/3svtZtvPnze0DjFRLLhPAVM18wFXjNVq0BtHUSBURQMB
oPkhpkT/Ky4V8JmzZ5UJfuK1oC1La0g+IK7Sb8gDN39OUdbAD6y4BqFzTTw9u6Gy
vMIF6Aznj9fnuseXnH2BigGYKFvRdsIipBwfAQfHmYDK4KKaRNKMnWvlFMvT9li9
uQpSAgblzaqajj5i/4SCt+rgUnjPEviwJ7HMbuLJg88djFpEkgMTFusZJL8OCu5p
KhlhJs1MVXUB6CHJLEozALuIJ02rF4Ca6WkBHqQa6YgOk3pnaav/wEWt/bVJ6KFD
Fe3pKms30/LLcb7t5+rkeFCyYVskTw==
=jB/P
-----END PGP SIGNATURE-----

--nextPart1625463.McxDEkl6s1--