I'm sorry that this email created a new thread on externals.io - not sure
how to avoid that.
On Sun, 8 Jul 2018 at 18:51, Rudi Theunissen wrote:
> Hi everyone,
>
> This RFC is now final; no decision will be changed unless there is a very
> good reason to do so. I'm happy with the approach in det
Hi everyone,
This RFC is now final; no decision will be changed unless there is a very
good reason to do so. I'm happy with the approach in detail and available
to address any further concerns.
I'm waiting on the sidelines of the potential changes to the release
schedule, but would like to ask wh
Fixed! Thanks Christoph, I guess I've been typing "PHP" too much lately. :p
On Thu, 5 Jul 2018 at 11:30, Christoph M. Becker wrote:
> On 05.07.2018 at 16:27, Rudolf Theunissen wrote:
>
> > Somewhat related, and in response to Levi's mention of it in this thread,
> > I've added a frequently asked
On 05.07.2018 at 16:27, Rudolf Theunissen wrote:
> Somewhat related, and in response to Levi's mention of it in this thread,
> I've added a frequently asked question regarding Python 3's removal of
> __cmp__. Please see:
> https://wiki.php.net/rfc/object-comparison#why_did_python_3_remove_cmp_in_f
>
> We can just define that == calls __equals on the left. That's, for
> example, what Python does. This would produce a weird consequence of $a
> == $b and $b == $a not being the same, but that's what you get for
> overloading operators. That's why overloading operators is not always
> the best id
Hi!
> 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?
We can just define that == calls __equals on the left. That's, for
example, what Python d
On 1 July 2018 19:45:03 BST, Rudolf Theunissen
wrote:
>>
>> 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
>> b
>
> 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 it would be confusing to
On Thursday, June 28, 2018 9:47:56 PM CDT Rudolf Theunissen wrote:
> > 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,
On 30 June 2018 19:04:27 BST, Rudolf Theunissen
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 th
> I think it's fairly crucial that this proposal is NOT just about
overloading operators, it's about overloading *behaviour*
That is what this RFC is trying to achieve. Equivalent in behaviour, so
we're providing a way for a class to define how it compares or equates to
another value. We're not pr
On 27 June 2018 at 19:24, Levi Morrison wrote:
> This permits things such as NumPy to overload < to do an element-wise
> comparison of the members; something like this:
>
> np.array([1, 3, 5, 7]) < np.array([2, 1, 6, 6])
> // evaluates to np.array([true, false, true, false)
>
In my opin
>
> 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.
I'm not sure if I like this, it's a bit non-deterministic isn
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
> li
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 lik
>
> In summary, I propose that return type constraints should be removed
> which will allow us to pursue specific operator overloading at a later
> point if we desire
There are no return types or parameter types. The only requirement is that
the function is public and not static.
On Wed, 27 Jun
On Wed, Jun 27, 2018 at 12:24 PM Levi Morrison wrote:
>
> On Tue, Jun 26, 2018 at 5:50 PM Rudolf Theunissen
> wrote:
> >
> > Hi everyone,
> >
> > This is an RFC that is based on previous discussions here:
> > https://externals.io/message/102337
> >
> > RFC: https://wiki.php.net/rfc/object-compari
On Tue, Jun 26, 2018 at 5:50 PM Rudolf Theunissen
wrote:
>
> Hi everyone,
>
> This is an RFC that is based on previous discussions here:
> https://externals.io/message/102337
>
> RFC: https://wiki.php.net/rfc/object-comparison
>
> The implementation is tested and appears to be working as expected.
>
>
> > 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
On 27 June 2018 at 16:24, Michał Brzuchalski wrote:
> 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 {}
> }
> a
śr., 27 cze 2018 o 16:55 Michał Brzuchalski
napisał(a):
>
>
> śr., 27 cze 2018 o 03:29 Rudolf Theunissen
> 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
On 27 June 2018 at 14:30, Wes wrote:
> not some class, only same comparator function. e.g. this is ok, as __equals
> is the same for both classes
> trait X{ function __equals($o){ ... } }
> class A{ use X; }
> class B{ use X; }
> assert((new A) == (new B));
>
What does "the same function" mean,
śr., 27 cze 2018 o 03:29 Rudolf Theunissen
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 d
not some class, only same comparator function. e.g. this is ok, as __equals
is the same for both classes
trait X{ function __equals($o){ ... } }
class A{ use X; }
class B{ use X; }
assert((new A) == (new B));
> 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
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 equ
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 ==
Hi everyone,
This is an RFC that is based on previous discussions here:
https://externals.io/message/102337
RFC: https://wiki.php.net/rfc/object-comparison
The implementation is tested and appears to be working as expected. :)
- Rudi Theunissen
27 matches
Mail list logo
