Hi!
> I think if you want to push the RFC forward, a really quite strong
> case needs to be made for why having it be a language level feature is
> so much better (or even at all better) than having it be implemented
> in userland.
I tend to agree here. There are not that many cases where < and >
This discussion has moved to the RFC thread here:
https://externals.io/message/102473
On Mon, 25 Jun 2018 at 07:56, Rudi Theunissen wrote:
> The part I found difficult was in the handlers - we only have `compare`,
> no equals.
> The only way we can have the handler differentiate between equality
The part I found difficult was in the handlers - we only have `compare`, no
equals.
The only way we can have the handler differentiate between equality and
ordering
is if we pass a parameter to the handler, which means we'd have to change
the header.
From:
`typedef int (*zend_object_compare_zvals
>
> Java has .equals and .compareTo; these operations are separate. In
> Java neither integrates with operators.
Yeah that's right. I was just pointing out that Java's == always checks
against
the reference and you can't override it (so it's like PHP's ===). Their
.equals()
method is like PHP's =
On Sun, Jun 24, 2018 at 2:31 PM Rudi Theunissen wrote:
>>
>> Other languages (most? all?) separate equality and ordering for this reason.
>
>
> Java doesn't really separate them. Their `==` always checks object reference
> so is like PHP's ===.
> But they do have the .equals() method on all objec
>
> Since this is a method, and not just a callback passed somewhere, could
> we simply mandate that the signature has an "int" return type?
We can error internally if the return value wasn't an integer, and the user
is welcome
to add a `: int` to the signature, but I'm not sure if you can specif
On 24/06/2018 21:31, Rudi Theunissen wrote:
So with that in mind, maybe it's okay to take "NULL falls back to default
behaviour" idea out, and do a normalisation
on whatever the user returns. If it's NULL, then that'll be 0, and the
value will be equal. The only thing I don't like about
that is t
>
> Other languages (most? all?) separate equality and ordering for this
> reason.
Java doesn't really separate them. Their `==` always checks object
reference so is like PHP's ===.
But they do have the .equals() method on all objects (our ==) and the
collections use that for equality.
In these
On Sun, Jun 24, 2018 at 11:28 AM Rudi Theunissen wrote:
>
> The idea behind the nullable return is to allow for partial support, where
> you might want to check for
> equality but ignore ordering. You can't return nothing or NULL if we
> normalise to -1,0,1 because NULL
> would be 0 and therefor
The idea behind the nullable return is to allow for partial support, where
you might want to check for
equality but ignore ordering. You can't return nothing or NULL if we
normalise to -1,0,1 because NULL
would be 0 and therefore indicate that the values are equal.
We could require that the user a
On Sun, Jun 24, 2018 at 8:11 AM Rudi Theunissen wrote:
>
> Here is a WIP implementation of `__compareTo`, with some decent tests.
>
> https://github.com/php/php-src/compare/master...rtheunissen:rt-compare-to-magic-method?diff=unified
Help me understand the nullable return. If you are defining thi
Here is a WIP implementation of `__compareTo`, with some decent tests.
https://github.com/php/php-src/compare/master...rtheunissen:rt-compare-to-magic-method?diff=unified
On Fri, 22 Jun 2018 at 17:03, Rudi Theunissen wrote:
> On further investigation, I'm not sure if we need both `__equals` and
On further investigation, I'm not sure if we need both `__equals` and
`__compareTo`,
even with all the talk about contexts and the fact that an object can be
tested for
equality and not necessarily ordering as well. If we take out the
`__equals` method
and only include `__compareTo`, we can allow t
What's the best place to override == internally? `do_operation` or a new
object handler?
I'd like to separate equality from compare_function.. or should we ignore
`__equals `
and assume that the values are equal if `__compareTo` returns 0?
Here's some context: I'm modifying `is_equal_function` to
> Yes, that's the type of thing that I think needs to be included as
> part of the RFC.
>
> Including a list of all the (or at least the important) functions that
> would be affected by this RFC should be made both for clarity and so
> that people can think through any edge cases.
Absolutely. I w
On 22 June 2018 at 12:31, Rudi Theunissen wrote:
>
>> I think if you want to push the RFC forward, a really quite strong
>> case needs to be made for why having it be a language level feature is
>> so much better (or even at all better) than having it be implemented
>> in userland.
>
>
> 1. You
>
> In my opinion we should have functions which take comparator and/or
> equality functions as parameters even if we can override these
> operators.
I really like this idea, because it puts the responsibility of the
definition on the caller. It
allows you to do things like "Is there an instance
On Fri, Jun 22, 2018 at 6:39 AM Levi Morrison wrote:
>
>
> > 1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`, `!=`
> > with a userland implementation.
> > 2. Therefore, you won't be able to affect the internals of array functions
> > like `in_array`, `sort` etc.
>
> In my opinion
> 1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`, `!=`
> with a userland implementation.
> 2. Therefore, you won't be able to affect the internals of array functions
> like `in_array`, `sort` etc.
In my opinion we should have functions which take comparator and/or
equality funct
> If __compareTo($other) gives 0 then there is no justification for
additional method.
> IMO you're duplicating functionality here.
I tried my best to explain that this is not the case. There are perfectly
logical cases where
two values are not equal, but have the same relative ordering. The best
On 21 June 2018 at 10:27, Rudi Theunissen wrote:
> The Comparable RFC (http://wiki.php.net/rfc/comparable) was written in 2010
> but was not conclusive. I would like to take
> on some shared responsibility to push this forward and re-open the
> discussion.
>
> Why is this useful, and why should it
2018-06-21 11:27 GMT+02:00 Rudi Theunissen :
> The Comparable RFC (http://wiki.php.net/rfc/comparable) was written in
> 2010
> and
> revised in 2015 by Adam Harvey, but was not conclusive. I would like to
> take
> on some shared responsibility to push this forward and re-open the
> discussion.
>
>
22 matches
Mail list logo
