On 30 June 2018 19:04:27 BST, Rudolf Theunissen <rudolf.theunis...@gmail.com> 
wrote:
>We're proposing the ability for a user to determine how a class should
>be
>compared to another value. The ability to change the semantics of the
>comparison operators is an unavoidable side effect.

Absolutely, I agree with the intent of this RFC. I think what I was suggesting 
is that if people in future want to overload the operators specifically, we 
would want to provide an overload for <=> that was separate from __compareTo, 
so that you could overload that without breaking things like sorting.


>> I think __compareTo() and __equals() could act more like a return
>type
>hint, and either throw a TypeError straight away, or attempt to coerce
>to
>the correct type and throw a TypeError on failure.
>
>Currently they do attempt to convert to boolean and integer,
>respectively,
>but that doesn't achieve much because you can still return nothing in
>either case and the coercion would be 0 and false.

Apologies if this is covered in the RFC, but does that apply wherever they are 
used? For instance, what will the following code do?

class SpaceStation {
     public $shape;
     public function __construct($shape='[]') {
          $this->shape = $shape;
     }
     public function __compareTo($other) {
          return new self($this->shape . '>=<' . $other->shape);
     }
}

$a = new SpaceStation;
$b = new SpaceStation;

$c = $a <=> $b; // Error? 0?
echo $c->shape; // or will this echo '[]>=<[]'?

$d = $a < $b; // Same result?

$list = [$a, $b, $c, $d];
sort($list); // Or will the error only be raised here?



>The decision whether to accept this will come down to the trade-off
>between
>flexibility and potential for misuse. 

Absolutely, and for what it's worth (which isn't much) I'm +1 on this, if it's 
not documented as operator overloading (which I think is a separate feature) 
and can't be used to produce values outside the expected type (due to coercion 
or errors).

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to