Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender)
Message-ID: <693d4b9182d40310ef1f73e8f1599154.squirrel@www.l-i-e.com>
In-Reply-To: <op.vj3msppzidpuyk@damnation.dulce.lo.geleia.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>
Date: Wed, 6 Oct 2010 10:32:40 -0500
To: internals@lists.php.net
User-Agent: SquirrelMail/1.4.21 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] RFC: Comparable interface
From: ceo@l-i-e.com ("Richard Lynch")

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
>>
>> Errrr.
>>
>> Which one of these would you expect to be "true"?...
>>
>> They're sure not equal, right?
>>
>> And what would make $a or $b "greater" than the other? I mean, *WHY*
>> would you expect one of those to be "true", if you do expect one of
>> them to be "true"?
>>
>> I sure can't find any logical a priori ordering, total, partial, or
>> otherwise.
>>
>> Last time I checked, there was no "rule" that any set/graph or other
>> mathematical collection had to have a defined ordering, even
>> partial.
>>
>> But it's been ages since I got my Honors Math degree, so maybe they
>> changed the rule while I wasn't looking... :-)
>>
>
> Without addressing the appeal to authority argument, the problem is
> not
> that there "must" be an ordering, partial or total.
>
> The problem is that several algorithms expect a total order criterion
> to
> exist; a notable example are sorting functions. While many will still
> terminate when given a partial order, the results will be
> unpredictable.
> So basically 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.

Forcing one to exist because a function exists that requires a stable
full ordering in order to call that function...

That's like forcing any string to be a valid JPEG because you might
feed it to imagecreatefromstring(), in my eyes.

> Note that e.g. Java and .NET require a total order, see:

PHP is not Java.
PHP is not .Net

I really don't see a valid reason why any given random collection of
OOP instances would a priori have to have a total ordering available
to them.

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.

> 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?

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE