On 01/19/2015 08:29 AM, Andrea Faulds wrote:
Hey Nikita,
On 19 Jan 2015, at 14:07, Nikita Popov <nikita....@gmail.com> wrote:
I like the idea behind this (exposing internal compare_function), but I don't
want to have an extra operator for a minor use case. Please just introduce a
function instead.
I originally wanted a function, but an operator has some advantages. There’s no
backwards-compatibility issues from function name conflicts (nor do we have to break with
tradition and use a namespace despite everything else not having one). The syntax is similar to
other comparisons: we don’t have lt(), gt(), lt_or_eq(), gt_or_eq(), eq() and not_eq(), we have
<, >, <=, >=, == and !=. Why, then, should we have cmp() or compare()? We get to fix
one of C’s mistakes here, in that C (unlike FORTRAN of all things) failed to provide a three-way
comparison operation despite it being useful and often available natively. <=> has a
certain brevity and is familiar to Ruby and Perl users.
Plus, it looks cool and has a cool name (not really an argument, I know).
Still, there is a case for a function, but I’m trying for an operator for now.
I quite like how this feature makes multi-item comparisons much simpler.
--
Andrea Faulds
http://ajf.me/
This looks potentially quite useful, especially for multi-stage
comparisons as you note. Mainly it would mean I don't have to remember
which direction is positive or negative, as I can never get that right
without looking it up. :-)
The examples say nothing about mixing types, though. Eg, what would
these return:
return 0 <=> "0"
return "" <=> 0
return 1 <=> [1, 2, 3]
Ignoring object property names and going by the order of the property
definition seems like asking for trouble, too.
There may be easy logical answers to the above given PHP's existing type
juggling, but they should be called out explicitly in both the RFC and
in any subsequent documentation.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
