Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102546
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: Sat, 30 Jun 2018 20:29:13 -0500
Message-ID: <10630585.pfV4cjzRZt@vulcan>
In-Reply-To: <CAHFNTwf0=Nd4DMx=T4DTY2DqJaKLoTkQ_Y9JRWK8u0asSfyxdQ@mail.gmail.com>
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com> <CAPKYkKwJyH4JC7bN5MHdReRCL0QTjQi0vrCRN=88nm48Onx=Xw@mail.gmail.com> <CAHFNTwf0=Nd4DMx=T4DTY2DqJaKLoTkQ_Y9JRWK8u0asSfyxdQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4030138.PNvAGqfR0n"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: larry@garfieldtech.com (Larry Garfield)

--nextPart4030138.PNvAGqfR0n
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Thursday, June 28, 2018 9:47:56 PM CDT Rudolf Theunissen wrote:
> > 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.
> 
> I'm not sure if I like this, it's a bit non-deterministic isn't it.. that
> the comparison function
> called can be determined by the value being compared? While I'm not
> disregarding this
> idea entirely, it's another addition we can add at a later stage.
> 
> It would be a bit of a juggle internally, to hold on to the type error
> while we attempt the
> second call, and if that fails, we throw the type error of the first
> attempt?

Thinking on this more, I think we have to do it in some fashion.  The current 
rules in the RFC say:

* Check if $a has a __compareTo() method.  If so, use it.  Else:
* Check if $b has a __compareTo() method. If so, use it.  Else:
* Default behavior.

However, that ignores the case where $a has a __compareTo() that is not type-
compatible with $b.  In that case, the current rules in the RFC would imply 
"call $a with a type mismatch, get a TypeError", regardless of whether 
$b::__compareTo() would work."

I would suggest the better logic be:

if (either $a or $b have a __compareTo()) {
  if ($a->__compareTo() exists and is type compatible with $b) {
    use $a->:__compareTo()
  }
  else if ($b->__compareTo() exists and is type compatible with $a) {
    use $b->:__compareTo()
  }
  else {
    throw a new InvalidComparisonError (new type, extends TypeError)
  }
}
else {
  Default behavior
}

That way we don't need to track A's or B's type error, we just say "if either 
of these objects is opting in, do whatever we can.  If not, it means we don't 
want default behavior."  Obviously an untyped compareTo() method is always 
type compatible with anything, so developers can use that as they desire.


> I don't understand Future Scope point 1. It... means we're already covering
> 
> > those operators. Why is there future scope needed?
> 
> Python, for example, has the ability to override specific comparison
> operators, such as
> 
> > <chasepeeler@gmail.com>
> 
> __lt__ for <. Point 1 is trying to say that *if* we want to introduce full,
> specific operator
> overloading in the future, we would already have the magic methods for ==
> and <=>.


Oh, so it's just saying that implementing __lessThan() in the future is not 
blocked, as that would simply get checked before __compareTo() while 
__compareTo() would be the first thing called for <=>.  Gotcha.  I'm good with 
that.

--Larry Garfield
--nextPart4030138.PNvAGqfR0n
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/GXfY8v0YwFBp4MMKwDFxYXcFAls4LmkACgkQ4MMKwDFx
YXffuwf+KNAb0Qhdiu57TYyvW6DJ/P5YUu/CbEeiioOM9wHNs+D2ihrK2osJ3Qvj
LEC6RSNZXE5rAKW9m86sqtv548/fvIIwYTA5p1tBswkVmK07+cGXHGOP3i4jIaTW
KrgqXpzxRM9cgISE71Ko6s9XD6sXSVOWgc0aszc+Snqtc+VsFcY7iL433EFfXNFt
jfcL1HuyGG1Don0psnj+SpDUy6J5Gn4JE4NIkC+I1b7ZdVp/ocR6xQJNSiuJmOER
ip5K42WbHUl6/qmVZgx/Enj0Ht9m+dEuGIxuy7HhStPBkOhChJKupwFUSTr/QB1K
XWpE9JnyMkmfwXsIcBCuDW/JwhKAVA==
=Rx8+
-----END PGP SIGNATURE-----

--nextPart4030138.PNvAGqfR0n--