> > > > If $left operand and $right operand both have the magic methods, it will > call $left->__magic($right), otherwise, if only the right one has the > handler? What if the right one has compareTo and the left has only equal? > you probably should add a table that explains which method is called > depending in the availability of the two magic methods in the operands. > > I think $left == $right => $left->__equals($right) makes perfect sense.
$left dictates fallbacks, since $left is the one invoking the method. If $left doesn't have __equals, then it uses __compareTo... if it doesn't have either, it falls back to the original way. Bottom line, the existence or non-existence of either method on the right side doesn't matter. As with all type juggling, you run the risk that ($a == $b) !== ($b == $a). The other option would just be to force both objects to define at least the __compareTo method, and if one of them doesn't, it falls back to the old way. I woudn't go as far as requiring they be the same functions though... existence should be good enough. Maybe throw a warning if used for classes of different types or where the methods are different - but if I have class Apple and class Orange, and want to compare them, I should be able to do so! Has implementing this using an interface? Just like ArrayAccess defines methods that allow object to be referenced like an array, Comparable could provide methods (equals and comparesTo) that would override the comparison operators. Personally, I like magic methods, so I'm good with the RFC as-is. -- -- Chase chasepee...@gmail.com
