Re: [RFC] User-defined object comparison

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

Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc