Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <AANLkTimG-BJyqvf5-6iFJ5Q6e5FouL+9mnkTNVmsKi+r@mail.gmail.com>
 <1285856641.16846.92.camel@guybrush>
 <alpine.DEB.2.00.1009301547030.2461@kossu.derickrethans.nl>
 <AANLkTikpiKnm2fAVwbumFdsnOoCVib0GPKtBKaKn6Mev@mail.gmail.com>
 <1286115365.2606.302.camel@guybrush>
 <op.vjz7iai6idpuyk@damnation.dulce.lo.geleia.net>
 <1286116661.2606.313.camel@guybrush>
 <op.vj0gft1zidpuyk@damnation.dulce.lo.geleia.net>
 <f84da711fd028f40ebb9c0c8892de1fd.squirrel@www.l-i-e.com>
 <op.vj3msppzidpuyk@damnation.dulce.lo.geleia.net>
 <693d4b9182d40310ef1f73e8f1599154.squirrel@www.l-i-e.com>
Date: Wed, 06 Oct 2010 17:04:10 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vj5v88k0idpuyk@damnation.dulce.lo.geleia.net>
In-Reply-To: <693d4b9182d40310ef1f73e8f1599154.squirrel@www.l-i-e.com>
User-Agent: Opera Mail/10.62 (Win32)
Subject: Re: [PHP-DEV] RFC: Comparable interface
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Wed, 06 Oct 2010 16:32:40 +0100, Richard Lynch <ceo@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 <ceo@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