On Wed, 06 Oct 2010 16:32:40 +0100, Richard Lynch <c...@l-i-e.com> wrote:
On Tue, October 5, 2010 5:44 am, Gustavo Lopes wrote:
On Tue, 05 Oct 2010 04:31:14 +0100, Richard Lynch <c...@l-i-e.com> wrote:
On Sun, October 3, 2010 12:34 pm, Gustavo Lopes wrote:
* The current behavior for >, <, etc. is completely useless. It's
unpredictable and it doesn't even establish a total order:
$a = new stdclass;
$a->prop = null;
$b = new stdclass;
$b->prop2 = null;
var_dump($a > $b); //false
var_dump($a == $b); //false
var_dump($b > $a); //false
[...]
Last time I checked, there was no "rule" that any set/graph or other
mathematical collection had to have a defined ordering, even
partial.
[...]
[...] the problem is not that there "must" be an ordering, partial or
total.
[...] You have comparison function for objects, but you cannot,
in general, use it to sort even objects of the same class (seem my
example).
But surely the generic case of an "Object" simply doesn't HAVE a
partial much less total ordering.
[...]
Note that e.g. Java and .NET require a total order, see:
PHP is not Java.
PHP is not .Net
I'm sorry, is this an argument?
You obviously don't know and didn't bother to check the details of the
Comparable interfaces in those languages and therefore did not understand
my point. They require a total ordering because that's precisely the only
way the comparison function can be useful for most applications. But
precisely because it doesn't make sense, as you say, to have total
ordering for the full set of objects, not all objects implement such
interface.
This contrasts with PHP, which allows without error comparison of all
objects, but you can't do anything useful with it.
Certainly, I can see a zillion cases where domain-specific knowledge
of the objects and a comparison function/operator should be definable.
But I strongly object to forcing EVERY random collection of objects to
have a total ordering. It's creating order where order does not
exist.
I don't care either way, but, if implemented an arbitrary total order
(e.g. using the object id), it wouldn't be worse than the status quo.
It would be somewhat useful to be able to sort objects by some
(arbitrary)
total ordering criterion, e.g. to do a binary search afterwards, but
that's marginal to my argument, which is that the current object
comparison behavior ranges from limited to useless. Therefore, some
addition that would allow the user to give meaningful behavior to the
operators in some limited circumstances (e.g. comparisons inside
classes with inheritance relationships only) would be a good idea.
I can certainly see why it would be useful to allow it in some cases.
But how tricky is it to write:
function foo_cmp($foo1, $foo2){ ... }
and hand that to usort?
It's not tricky, but it's besides the point. We don't need many other
operators either, we could just write a custom function and use it instead.
The point is -- I'm going to reiterate this one last time -- for objects,
you can't do anything useful with the current zend_compare_function,
therefore a limited mechanism for overloading it would be useful.
Notice you didn't provide any argument otherwise and instead admitted (for
whatever reason) I was defending a total order should be established for
all the objects.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
