Hi everyone,
Since it's been two weeks and there are no remaining issues (aside from the lack of a language specification patch - but that can be done later), I'm opening voting on this RFC.
Voting starts today (2015-02-02) and ends in two weeks' time (2015-02-16). As this adds to the PHP language (and hence affects the PHP language specification) a 2/3 majority is required for acceptance.
The RFC, which contains the voting widget, can be found here: https://wiki.php.net/rfc/combined-comparison-operator
Thanks!
--
Andrea Faulds
http://ajf.me/
Hi everyone,
Since it's been two weeks and there are no remaining issues (aside from
the lack of a language specification patch - but that can be done later),
I'm opening voting on this RFC.Voting starts today (2015-02-02) and ends in two weeks' time (2015-02-16).
As this adds to the PHP language (and hence affects the PHP language
specification) a 2/3 majority is required for acceptance.The RFC, which contains the voting widget, can be found here:
https://wiki.php.net/rfc/combined-comparison-operatorThanks!
I've voted -1 because I think this should be a function and not an
operator. compare($a, $b) is more obvious than $a <=> $b and it's not like
writing comparison functions is such a super common use case that it needs
the extra brevity of an operator. A function can furthermore be used as a
callback, while an operator requires a wrapping closure.
Nikita
I've voted -1 because I think this should be a function and not an
operator. compare($a, $b) is more obvious than $a <=> $b and it's not like
writing comparison functions is such a super common use case that it needs
the extra brevity of an operator. A function can furthermore be used as a
callback, while an operator requires a wrapping closure.
I support what Nikita said, but it doesn't influence my vote; I see them
separate.
Btw, I would be hesitant to introduce such a common name 'compare'.
thanks,
- Markus
Hey Nikita,
I've voted -1 because I think this should be a function and not an operator. compare($a, $b) is more obvious than $a <=> $b and it's not like writing comparison functions is such a super common use case that it needs the extra brevity of an operator. A function can furthermore be used as a callback, while an operator requires a wrapping closure.
There’s no actual use for the bare comparison operation as a callback, though: usort($foo, ‘compare’); would just be a slow version of sort($foo);
I agree that having it be available as a function might be useful in some cases, but this is also true of most operators. I think it would be better to add some means of obtaining a closure for PHP’s operators, however.
Thanks.
Andrea Faulds
http://ajf.me/
Hey Nikita,
I've voted -1 because I think this should be a function and not an operator. compare($a, $b) is more obvious than $a <=> $b and it's not like writing comparison functions is such a super common use case that it needs the extra brevity of an operator. A function can furthermore be used as a callback, while an operator requires a wrapping closure.
There’s no actual use for the bare comparison operation as a callback, though: usort($foo, ‘compare’); would just be a slow version of sort($foo);
For this particular use-case you are correct, but usually I use custom
callbacks for something more interesting, such as comparing one value
and then comparing another based on the result. Perhaps the callback
is higher-level:
function (callable $comparator) {
return function ($selector) use ($comparator) {
return function ($a, $b) use($selector, $comparator) {
return $comparator($selector($a), $selector($b));
};
};
}
Maybe I'm the only one doing stuff like this, but it's not uncommon for me ^^
Hey Nikita,
I've voted -1 because I think this should be a function and not an
operator. compare($a, $b) is more obvious than $a <=> $b and it's not like
writing comparison functions is such a super common use case that it needs
the extra brevity of an operator. A function can furthermore be used as a
callback, while an operator requires a wrapping closure.There’s no actual use for the bare comparison operation as a callback,
though: usort($foo, ‘compare’); would just be a slow version of sort($foo);
It may not be applicable to a direct sort() call, but it's useful for
higher level APIs. With a function you can create APIs of the form
function foo(..., $comparator = 'compare') { ... }, which will default to
the "standard" comparison function without having to specially handle it
all over the place.
Nikita
Hey Nikita,
Hey Nikita,
I've voted -1 because I think this should be a function and not an operator. compare($a, $b) is more obvious than $a <=> $b and it's not like writing comparison functions is such a super common use case that it needs the extra brevity of an operator. A function can furthermore be used as a callback, while an operator requires a wrapping closure.
There’s no actual use for the bare comparison operation as a callback, though: usort($foo, ‘compare’); would just be a slow version of sort($foo);
It may not be applicable to a direct
sort()call, but it's useful for higher level APIs. With a function you can create APIs of the formfunction foo(..., $comparator = 'compare') { ... }, which will default to the "standard" comparison function without having to specially handle it all over the place.
Yes, that’s true.
I’d previously suggested adding a function to get a closure of an operator. But actually, perhaps we should just follow PHP’s traditional string typing of callables, and make ‘+’, ‘-‘, ‘<‘, ‘<=>’ etc. be valid callables?
Thus:
function doesThing($a, $b, callable $callback = ‘+’) {
return $callback($a, $b);
}
doesThing(1, 2); // 3
Thoughts?
(I realise this is slightly OT.)
--
Andrea Faulds
http://ajf.me/
Since it's been two weeks and there are no remaining issues (aside from the lack of a language specification patch - but that can be done later), I'm opening voting on this RFC.
I just noticed that you kept T_SPACESHIP; while that is fun I don't
think it is appropriate. It is a common name for the operator, but
there are other common names as well. Even though I am undecided on
the merit of the RFC I am voting "no" because of this detail.
Since it's been two weeks and there are no remaining issues (aside from the lack of a language specification patch - but that can be done later), I'm opening voting on this RFC.
I just noticed that you kept T_SPACESHIP; while that is fun I don't
think it is appropriate. It is a common name for the operator, but
there are other common names as well. Even though I am undecided on
the merit of the RFC I am voting "no" because of this detail.
Google "spaceship operator", now imagine adding "php", reconsider :)
It is not about funny but easiness to find it and what it is all about.
--
Pierre
@pierrejoye | http://www.libgd.org
Hello,
I personally would use spaceship operator often, but only if PHP had
operator overloading for classes. So I hope it will pass and operator
overloading will pass someday as well (but operator overloading would
probably require method overloading first and that's a thing you guys
oppose, right?).
Regards
Pavel Kouril
Hi!
I personally would use spaceship operator often, but only if PHP had
operator overloading for classes. So I hope it will pass and operator
PHP has operator overloading for classes, but just for internal ones.
See: https://wiki.php.net/rfc/operator_overloading_gmp
For userspace ones, the feeling is unlimited overloading would be a bit
too chaotic.
Stas Malyshev
smalyshev@gmail.com
Hi!
I personally would use spaceship operator often, but only if PHP had
operator overloading for classes. So I hope it will pass and operatorPHP has operator overloading for classes, but just for internal ones.
See: https://wiki.php.net/rfc/operator_overloading_gmpFor userspace ones, the feeling is unlimited overloading would be a bit
too chaotic.Stas Malyshev
smalyshev@gmail.com
Hello,
yeah, I meant userspace operator overloading. I don't think it would
be chaotic - for instance C# allows it and it comes in handy sometimes
and is not chaotic at all.