śr., 27 cze 2018 o 16:55 Michał Brzuchalski <mic...@brzuchalski.com>
napisał(a):

>
>
> śr., 27 cze 2018 o 03:29 Rudolf Theunissen <rudolf.theunis...@gmail.com>
> napisał(a):
>
>> > I would like to see this in an extension first, i think it's perfectly
>> doable and people can test it before merging to core
>>
>>
> It was possible in Sara's extension[1], so maybe now also? Take a look.
>
>
>
>> Actually not sure this can be done as an extension because it changes
>> zend_operators and introduces a new handler to make it all work.
>>
>> > Would be nice if compareTo and equals were used only if left operand and
>> right operand used the same comparator function.
>> In other words, $a == $b must not work if $a->__equals and $b->__equals
>> are
>> two different functions
>>
>> So effectively it means we only call __equals if both sides are instances
>> of the same class?
>>
>> > 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.
>>
>> Good idea. :) In brief, as it's implemented right now, the LHS takes
>> precedence and the RHS will be called if it's the only one that implements
>> the operation. I'll write some more tests for these cases and build that
>> table for the RFC.
>>
>> > I'd introduce a debug mode that forces php to call both
>> $left->__equals($right) and $right->__equals($left) so that symmetry is
>> guaranteed by design.
>>
>> If we want to guarantee symmetry by design, we have to either compare both
>> sides or only compare if instances of the same class, or document that
>> comparison should be implemented such that a > b == b < a, etc. I'm not
>> convinced that a double comparison outweighs the responsibility on the
>> user
>> to be sensible.
>>
>> On Tue, 26 Jun 2018 at 21:04, Wes <netmo....@gmail.com> wrote:
>>
>> > some ideas and concerns:
>> >
>> > - I would like to see this in an extension first, i think it's perfectly
>> > doable and people can test it before merging to core
>> >
>> > - would be nice if compareTo and equals were used only if left operand
>> and
>> > right operand used the same comparator function.
>> > In other words, $a == $b must not work if $a->__equals and $b->__equals
>> > are two different functions
>> >
>> > - otherwise RFC should specify the precedence. 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'd introduce a debug mode that forces php to call both
>> > $left->__equals($right) and $right->__equals($left) so that symmetry is
>> > guaranteed by design. You could do that when "assertions" are active.
>> >
>> > gl
>> >
>>
>
> [1] https://github.com/php/pecl-php-operator/blob/master/operator.c
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>


There is also one more thing I can think of. If __equals and __compareTo
methods
don't have any restrictions for $other parameter typehint then I'll be able
to declare
Foo {
    public function __compareTo(int $other): int {}
}
and will get some error on
new Foo() == new DateTime('now');

Right?

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Reply via email to