Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102489
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain brzuchalski.com from 188.165.245.118 cause and error)
MIME-Version: 1.0
References: <CAHFNTweakKC+=+UJCWfD0ONcsrVH7rEKrOhnWObeGD+7TBQLjQ@mail.gmail.com>
 <CAOv67gv3OQuLHqKC++BD7A_-fJgzHLkdoc2BnpvD-t5jWGYo-g@mail.gmail.com>
 <CAHFNTwfdyzE_paxh2owFy=8wY0WNijLC2pdL0vAjjOYiXUPv=A@mail.gmail.com> <CABdc3WrcYiQT93aEPLT75D+fZqcevoR9qh+=u1XqUYvzRiq9xg@mail.gmail.com>
In-Reply-To: <CABdc3WrcYiQT93aEPLT75D+fZqcevoR9qh+=u1XqUYvzRiq9xg@mail.gmail.com>
Date: Wed, 27 Jun 2018 17:24:08 +0200
Message-ID: <CABdc3Wp8VW5KZMPhyhMghPkoEDV1AU27dmK=2ES-0DAXJEz3=w@mail.gmail.com>
To: rudolf.theunissen@gmail.com
Cc: Wes <netmo.php@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006fc1ab056fa13599"
Subject: Re: [PHP-DEV] [RFC] User-defined object comparison
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--0000000000006fc1ab056fa13599
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=C5=9Br., 27 cze 2018 o 16:55 Micha=C5=82 Brzuchalski <michal@brzuchalski.c=
om>
napisa=C5=82(a):

>
>
> =C5=9Br., 27 cze 2018 o 03:29 Rudolf Theunissen <rudolf.theunissen@gmail.=
com>
> napisa=C5=82(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 a=
nd
>> right operand used the same comparator function.
>> In other words, $a =3D=3D $b must not work if $a->__equals and $b->__equ=
als
>> are
>> two different functions
>>
>> So effectively it means we only call __equals if both sides are instance=
s
>> of the same class?
>>
>> > If $left operand and $right operand both have the magic methods, it wi=
ll
>> 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 implemen=
ts
>> 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 bo=
th
>> sides or only compare if instances of the same class, or document that
>> comparison should be implemented such that a > b =3D=3D 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.php@gmail.com> wrote:
>>
>> > some ideas and concerns:
>> >
>> > - I would like to see this in an extension first, i think it's perfect=
ly
>> > 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 =3D=3D $b must not work if $a->__equals and $b->__e=
quals
>> > 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 i=
s
>> > 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=C5=82 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() =3D=3D new DateTime('now');

Right?

--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--0000000000006fc1ab056fa13599--